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palavras-chaves dos seus trabalhos. 
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Editar uma revista não é uma tarefa fácil. E, torna-se cada vez mais difícil, se 
desejarmos responder positivamente às inúmeras sugestões e críticas, dirigidas pelos 
nossos leitores, a números anteriores. Difícil se contarmos com meios escassos e com 
poucas boas vontades. 

Para o leitor da nossa revista é determinante que os assuntos abordados lhe 
digam, de algum modo, respeito, isto é, que reflictam aspectos do seu trabalho 
quotidiano. Deste modo, os artigos deveriam, por um lado, ter um carácter descritivo e, 
por outro lado, ter um carácter pedagógico. Os artigos seriam assim instrumentos úteis 
de trabalho. Tais artigos deveriam ser escritos pelos informáticos que esperariam por 
artigos mais técnicos ou científicos, os quais deveriam por sua vez ser objecto da 
atenção dos académicos ou dos cientistas. 

Mas, os artigos não chegam para construir uma revista. Os leitores pretendem 
ainda informações sobre os novos produtos, o que se faz aqui e acolá, de forma a 
aproveitarem o trabalho desenvolvido algures e evitarem repetições fastidiosas. Tam- 
bém neste ponto, os informáticos em geral deveriam ter uma palavra a escrever. 
revista caberia então reportar essas experiências, através de um contacto assíduo com 
os centros de informática. Mas, nem os informáticos portugueses escrevem, nem a 
redacção da revista tem meios humanos (profissionais) para enviar aos centros. A 
revista foi e é feita por boas vontades, durante os seus tempos de lazer, e a título 
gracioso. 

Neste contexto particular, temos ensaiado alguns melhoramentos (caso das repor- 
tagens e entrevistas), e envidado esforços para planear as actividades editoriais. O 
presente número é um exemplo concreto de uma revista concebida, planeada, e 
executada ao longo de 12 meses. Mas, irá ela responder aos desejos dos nossos 
leitores? Não sabemos, mas pensamos que nem todos ficarão contentes. No entanto, o 
esforço de organização e o trabalho realizado foram notáveis. E nem sempre tivémos, 
daqueles que contactámos, a melhor resposta e O sentido de colaboração que havía- 
mos previsto quando decidimos deitar mão a esta obra. 
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INFORMÁTICA 


ponto de vista 


A «Informática de Gestão» 


na encruzilhada. 


História sucinta dum número 


especial 


1. MOTIVAÇÃO PARA O TRABALHO 
1.1 Antecedentes 


Desde que fomos convidados para a redacção da 
revista que temos vindo a defender a tese de que 
existe um hiato entre as preocupações profissionais 
da maioria dos seus potenciais leitores e o conteúdo 
da maior parte dos artigos aí publicados. Com efeito, 
parece-nos um facto indismentível que a maioria dos 
profissionais informáticos se insere na área da ges- 
tão, sendo igualmente uma realidade que a revista 
não tem tratado essa área com a proeminência que 
ela exige. Esta preocupação é, de resto, partilhada 
por muitos de nós, e aparece retratada num dos 
artigos deste trabalho. 

As causas desta situação são múltiplas e comple- 
xas, abrangendo um leque que vai desde a pouca 
propensão para a realização dos relatórios dos tra- 
balhos que realizamos (como, por exemplo, é norma 
para os trabalhos realizados na área do cálculo cien- 
tífico), até à escassez de tempo ocasionado, em 
parte, pela ausência de planeamento que se verifica 
na maioria das organizações — exige-se, quase 
sempre, que os trabalhos sejam realizados «para 
ontem». 

No entanto, todos os que, como nós, trabalham na 
informática de gestão, reconhecemos a necessidade 
de transmitirmos e recebermos os frutos dos nossos 
(insucessos; discutirmos metodologias de desenvol- 
vimento de projectos, de análise e de programação; 
expôrmos os nossos pontos de vista sobre a forma- 
ção e/ou reciclagens; reflectirmos sobre as nossas 
condições de trabalho, etc. 

Aliás, a quase ausência de intervenção dos infor- 
máticos que trabalham na área de gestão não se 
circunscreve — infelizmente — à revista. Na ver- 
dade, também ao nível dos congressos e outras 
sessões públicas essa ausência se tem feito sentir. 


1.2 A Gestão, a Informática. 


O termo informática de gestão (I.G.) aparece mui- 
tas vezes como o oposto da informática científica (ou 
de cálculo científico), gerando desde logo uma con- 
sequência — a 1.G. não é científica e, o que vem dar 
ao mesmo, não utilizaria cálculo científico. 

A informática de gestão caracterizar-se-ia, por um 
lado, por uma fraca utilização da capacidade da me- 
mória central do computador devido a pouca comple- 
xidade dos cálculos inerentes e, por outro pela ne- 
cessidade de se utilizarem peiféricos adequados à 
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rande necessidade de armazenamento de dados 
disco, banda) e de saída de mapas. Pelo contrário, 
a informática científica exigiria a utilização de me- 
mórias centrais potentes para a realização de cál- 
culos altamente complexos (álgebra matricial, mo- 
delos estocásticos) enquanto que, as necessidades 
de armazenamento e saída de dados seriam diminu- 
tas. Esta dicotomia seria também espelhada na utili- 
zação de linguagens distintas (Cobol versus Fortran). 
Esta abordagem terminológica tem feito correr rios 
de tinta e gerado no seio da comunidade informática 
algumas questões nem sempre pacíficas. 
o nosso ponto de vista, as diferenças entre as 
«duas informáticas» não se situam tanto ao nível 
dos aspectos atrás apontados. Com efeito, os instru- 
mentos clássicos de gestão (balanços, rácios) estão 
a ser rapidamente subalternizados em favor de no- 
vas técnicas que envolvem a utilização de instru- 
mentos mais potentes (programação linear, análise 
de séries, simulação, etc.). Efectivamente, o próprio 
conceito de gestão está em mutação como ficou 
patenteado, por exemplo, na | Conferência de Eco- 
nomistas realizada recentemente em Lisboa. Os no- 
vos conceitos impõe-se, inclusivé, na própria Admi- 
nistração Pública — tradicionalmente mais lenta na 
absorção de novas técnicas, onde em vários depar- 
tamentos se começa a pensar em termos de gestão 
integrada nomeadamente ao nível dos orçamentos- 
-programas. É assim que têm vindo a ser implemen- 
tadas, embora com ajustamentos, aplicações do 
P.P.B.S. (Planning, Programming, Budgeting Sys- 
tem), já largamente difundidas nos EUA e na Euro- 
pa. Para se ter uma ideia do que representa esta 
metodologia, basta referir que ela se apoia nos se- 
guintes items: 


— Levantamento das necessidades a curto e mé- 
dio prazo; 

— Selecção dos objectivos adequados à satisfa- 
ção das necessidades; 

— Implementação de programas que tornem exe- 
quíveis as metas apontadas; 

— Provimento financeiro dos programas; 

— Análise e correcção dos eventuais desvios en- 
tre o programado e c efectivamente realizado. 


Esta listagem deixa perceber o que o P.P.B.S. 
representa tanto ao nível da gestão — pressupondo 
uma gestão por objectivos aos vários níveis —, 
como ao nível da informática — exigindo a utilização 
de novos mecanismos ao nível da dotação dos pro- 
gramas e do seu controle sistemático. 
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ponto de vista 


É, no entanto, ao nível empresarial que as trans- 
formações de conceitos são mais rápidos pois que a 
actividade das empresas se insere num ambiente de 
conflitos vários que abrangem todo um espaço que, 
em muitos casos, é multinacional e com horizonte 
temporal que se pretende o mais dilatado possível. 
Só as empresas, que conheçam o ambiente onde 
desenvolvem a sua actividade e as grandes linhas 
de evolução que a pautuam, é que podem sobrevi- 
ver. O reconhecimento desta situação, levou à for- 
mulação de novos conceitos para ajuda à tomada de 
decisões nas organizações, aparecendo então os 
sistemas iteractivos de previsão de mercados, a eco- 
nometria — utilização de modelos de equações múl- 
tiplas para a representação esquemática da 
realidade —, as equações de comportamento técnico 
(funções de produção), as técnicas de pós- 
-Optimização e paramétricas, etc... 

Ora, sendo a informática apenas um dos instru- 
mentos a utilizar para a prossecução dos objectivos 
das organizações, é evidente que também ela evolui 
acompanhando necessariamente as mudanças atrás 
referidas, donde ter que se aceitar que também ao 
nível da informática de gestão, a utilização do cál- 
culo científico é (ou será) trivial. É neste sentido que 
defendemos a tese atrás exposta sobre a gradual 
aproximação entre as «duas informáticas». 

Na nossa perspectiva, a verdadeira diferença entre 
ambas reside a um outro nível. Assim na medida em 
que as soluções informáticas se dirigem sempre 
para a organização onde exercem, por vezes, um 
impacto muito grande, elas exigem a adopção de 
metodologias de desenvolvimento de projectos en- 


quadrados, no planeamento da empresa. Essas me- 
todologias devem ter em conta questões que, até um 
certo ponto, estão a montante da informática, e que 
envolvem nomeadamente: 


— Definição do problema; 

— Objectivos a atingir; 

— Necessidades, prioridades e contexto do pro- 
blema; 

— Análise custo-benefícios; 

— Necessidades de potencial humano e eventual 
formação; 

— Necessidades de equipamento e software; 

— Calendarização das etapas (utilizando o PERT 
se for necessário). 


Esta abordagem tem, claramente, pouco a ver 
com as necessidades do cálculo científico sendo, por 
outro lado, vital à informática de gestão como 
garante duma automatização administrativa correcta 
e minimamente capaz de se poder adaptar, com 
eficácia, às mudanças provenientes quer do interior 
da empresa quer do seu exterior. 

Naturalmente que a realidade empresarial domi- 
nante entre nós pratica ainda uma gestão «por im- 
pulsos». A maioria das organizações utiliza ainda os 
conceitos clássicos de gestão devido ao nosso pro- 
verbial atraso sócio-económico. Mas, os sinais de 
mudança aí estão: a evolução do contexto econó- 
mico, social e institucional desde o início da década 
de 70 (e em particular desde 25 de Abril de 1974), 
tem sido rápida. O crescimento fácil da década de 
60 e o proteccionismo (pautal e condicionamento 
industrial), estão definitivamente ultrapassados. O 
que, provavelmente, espera as empresas portugue- 
sas é a entrada num mercado de 300 milhões de 
consumidores com empresas orientadas por proces- 
sos modernos de gestão. 
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O planeamento aos vários níveis tornar-se-á então 
indispensável. Assim, ao nível do planeamento estra- 
tégico (médio e longo prazo) terão de ser definidas 
as políticas globais, fixados os objectivos e delinea- 
dos os programas de acções estratégicos. O plano 
administrativo decorre do plano estratégico e fixa 
para cada área (produção, marketing, pessoal, finan- 
ças) os recursos adequados à prossecução dos ob- 
jectivos. Por sua vez, o plano operacional — 1 a 2 
anos — constitui uma implementação dos programas 
administrativos (ou tácticos) nos níveis intermédios 
de gestão. 

E a partir destas concepções que decorrem todas 
as informações para a gestão: plano de encargos 
médios de produção, cálculos de custos variáveis 
anuais, margens brutas, custos de estruturas, encar- 
gos financeiros, resultados de explorações previsio- 
nais, etc.. 

A informática terá, por sua vez, de satisfazer os 
requisitos das novas técnicas de gestão, fornecendo 
informação atempada e rigorosa para os vários ní- 
veis da pirâmide de decisão da organização. Ela terá 
que ser rentável, no sentido de se apresentar como 
um custo gerador de benefícios. A utilização de ba- 
ses de dados parece ser um dos instrumentos ade- 
po à obtenção, por um lado, duma integração 

a informação e, por outro, duma independência, 
embora sempre relativa, entre os próprios dados e a 
sua manipulação, aligeirando a manutenção dos pró- 
prios trabalhos de gestão que se tem revelado uma 
componente de custos informáticos extremamente 
onerosa. 

A mutação da informática face à renovação dos 
conceitos de gestão tem vindo a ser realizada com 
maiores ou menores sobressaltos. A este respeito 
gostaríamos de salientar a oportunidade do tema do 
1.º Congresso Nacional sobre Investigação Operacio- 
nal — a investigação operacional e suas aplicações 
à gestão — revelador das mudanças que se têm 
vindo a operar. Com efeito tem de ser reconhecida a 
importância da 1.0. para a gestão, dispondo-a de um 
vasto conjunto de poderosos instrumentos adequa- 
dos à tomada de decisão, no domínio das técnicas 
de Optimização de Decisões e de Simulação. 

E face a esta revolução de métodos que os inves- 
tigadores procuram adequar os conceitos (ultrapas- 
sados?) à nova realidade. 

Pertencemos ao grupo dos que admitem que o 
termo «informática de gestão» é, no mínimo, pobre e 
no sentido que damos à gestão, é, quiçá, inadequa- 
do. Mas é um facto que as novas contribuições 
terminológicas não nos parecem felizes — ou pecam 
por demasiado generalistas, como será o caso do 
termo «Informática nas Organizações», ou demasia- 
do parcelares como será o caso do termo «Informá- 
tica de Apoio à Decisão». O primeiro termo atrás 
apontado como sucedâneo da «Informática de Ges- 
tão» ultrapassa, em nosso entender, o conteúdo da 
informática que praticamos (e praticaremos) na me- 
dida em que incluiria naturalmente ramos da infor- 
mática como a Robótica, ou o Cálculo Científico que, 
claramente, são objecto de outras abordagens. O 
segundo termo é, por seu lado, demasiado estrito na 
medida em que os trabalhos que realizamos (e reali- 
zaremos) não se situam na área do Apoio à Decisão 
mas não deixam de ser relevantes como é o caso, 
por exemplo, do processamento de salários. 

Correndo o risco de parecermos conservadores 
julgamos que, apesar de tudo, o termo «Informática 
de Gestão» com que baptizámos o trabalho apresen- 
tado, é o que melhor reflecte a nossa actividade 
além de possuir o mérito evidente de já ter sido 
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consagrado pela prática. Aliás, também noutras ciên- 
cias pudemos verificar alguma inexactidão nos con- 


ceitos. Para darmos um exemplo, entre muitos pos- . 


síveis, o termo Economia Política é, como sabemos, 
inquestionável. No entanto, uma análise etimológica 
do conceito revela-nos a sua inexactidão — Econo- 
mia é a administração doméstica e Política como 
sabemos, é a cidade, donde o termo designaria a 
«administração doméstica da cidade», o que além 
de paradoxal, não tem a ver rigorosamente nada 
com o campo de estudo daquela ciência. Este facto, 
por seu lado, não impede os economistas de sa- 
berem a que se referem quando utilizam aquele 
termo. 


2. APRESENTAÇÃO DO TRABALHO 
2.1 Balanço 


Tal como no balanço das empresas, também aqui 
poderíamos tentar apresentar o Activo e o Passivo 
deste trabalho ficando assim (matematicamente) de- 
terminado se os resultados do exercício tem o carác- 
ter de lucro ou de perdas. 

No contexto desta metáfora, serão os leitores a 
assumirem o papel do Conselho Fiscal. 

No activo e evidentemente como «Imobilizado Ma- 
terial» (ou Corpóreo) aparecem os artigos e inquéri- 
tos que são objecto deste trabalho. «A priori» propu- 
semo-nos alcançar dois objectivos: 


— Abarcar uma pluralidade de temas essencial- 
mente virados para a nossa realidade; 

— Convidar para autores desses temas pessoas 
inseridas na área da Informática de Gestão 
com sensibilidades várias e situados em níveis 
de decisão distintos. 


Passamos a apresentar uma breve síntese dos 
artigos e da caracterização dos seus autores, para 
demonstração de até onde aqueles objectivos foram 
(ou não) atingidos. 


A GESTÃO DE TERCEIROS. 
UMA APROXIMAÇÃO PELAS BASES DE DADOS 


— Trata-se dum artigo que apontando um tí- 

pico problema de gestão, propõe para a 
sua solução informática a utilização duma 
ferramenta poderosa — as bases de 
dados. 
O autor é licenciado em Economia e traba- 
lha em Informática de Gestão desde 1974. 
Actualmente é consultor informático na 
Quimigal, pertence aos Corpos Gerentes 
da API e integrou a Comissão Organiza- 
dora do 1.º CPI. 


GESTÃO DE PESSOAL 


— É um trabalho com as características bási- 
cas do anterior, procurando situar a função 
pessoal num conceito de gestão integrada 
e tendo em vista atingir um objectivo caro 
à Informática de Gestão — a transportabili- 
dade do software. 

Isto é, a solução informática proposta deve 
ser aplicável a todas as empresas. O autor 
trabalha em informática desde 1972 tendo 
sempre desempenhado funções em gran- 


ponto de vista 


des centros informáticos (TAP e CGD). Ac- 
tualmente trabalha na LOCAPOR sendo, 
além disso, colaborador assíduo do suple- 
mento de informática do «Jornal». 


AUDITORIA INFORMÁTICA 


— Neste artigo equaciona-se o papel cres- 
cente da auditoria nas organizações. Esse 
papel tem vindo a exigir o abandono dos 
pressupostos da auditoria tradicional (con- 
tabilística) exigindo conhecimentos poten- 
tes de duas áreas — Gestão e 
Informática — o que releva o papel do au- 
ditor informático. O autor trabalha em In- 
formática de Gestão desde 1971 tendo de- 
sempenhado funções múltiplas de forma- 
ção, consultudoria, auditoria, etc.. Actual- 
mente, além de consultor de várias organi- 
zações é responsável duma «Software 
House». 


FORMAÇÃO EM INFORMÁTICA 


— O tema abordado neste artigo tem-se re- 
velado como um dos mais polémicos no 
seio da comunidade informática. O objecto 
deste trabalho é contribuir para uma dis- 
cussão do tema num contexto diverso da- 
quele que tem balizado a controvérsia. 
Sugere-se uma metodologia para a abor- 
dagem da questão atendendo aos seus 
antecedentes nomeadamente o 2.º ENI. O 
autor começou a trabalhar em informática 
em 1969 tendo desenvolvido actividades 
várias, entre as quais, programação, análi- 
se, formação e consultudoria. Integrou 
eira a Comissão Organizadora do 1.º 


O SOFTWARE DE APLICAÇÕES 

E AS TRANSFORMAÇÕES NAS ORGANIZAÇÕES: 
CONSIDERANDOS SOBRE A REPRESENTAÇÃO 
DO CONHECIMENTO 


— É um trabalho que nitidamente se situa na 
área da investigação. Propõe-se uma nova 
arquitectura de software capaz de respon- 
der a duas questões muito pertinentes 
para a informática em geral e para a infor- 
mática de gestão em particular: 

— dificuldades envolvidas na modificação do 
software como resposta a mudanças orga- 
nizacionais; 

— transportabilidade do conhecimento. 

O autor é actualmente investigador no In- 
ternational Institute for Applied Systems 
Analysis (ASA) tendo recentemente lec- 
cionado na Faculdade de Economia da 
UNL. 


INQUÉRITO — ALGUMAS APLICAÇÕES 
DE INFORMÁTICA DE GESTÃO 


— Pretendia-se, com este inquérito, divulgar 
e caracterizar algumas das aplicações de 
gestão administrativa realizadas em Portu- 
gal. Para o efeito, foram contactados cen- 
tros de informática situados em ramos de 
actividade distintos: União de Bancos Por- 
tugueses, Bonança, Quimigal, Lima Mayer, 
Editorial Verbo, Jerónimo Martins e Central 
de Cervejas. 
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INQUÉRITO — PANORAMA DOS EQUIPAMENTOS 
DE MEDIO E GRANDE PORTE 
COMERCIALIZADOS EM PORTUGAL 


— Tentamos apresentar uma imagem dos 
equipamentos de médio e grande porte 
comercializados em Portugal e que espe- 
cificamente se dirigem para a Informática 
de Gestão. A lista de representantes con- 
tactada — seleccionada do Anuário Geral 
de Informática — foi a seguinte: BUR- 
ROUGHS, CASSEL DATA, CMC, CON- 
TROL DATA, DATINFOR, HONEYWELL 
BULL, IBM, ICL, MAGNETROM, NCR, 
NOGUEIRA INFORMÁTICA, NIXDORF, 
OLIVETTI, Q1 PORTUGAL, QUADRI, 
REGISCONTA e SPERRY UNIVAC. 


2.2 Demonstração dos Resultados 


Como sabemos, o activo do balanço, atrás sumari- 
ado, deve ser financiado por determinadas fontes. O 
passivo será então representado por o trabalho que 
realizamos e que se traduziu em bastantes horas 
extras-profissionais — não remunerados — ocupa- 
dos na concepção do trabalho, nos seus aspectos 
gráficos e estruturais, na recolha do material, na sua 
dactilografia e correcção, na montagem e composi- 
ção, etc.. Estas tarefas tornam-se por vezes, árduas 
e mesmo frustrantes e, de facto, constituem aquilo 
que poderíamos designar, ainda em termos conta- 
bilísticos, como o «Não Exigível» do Passivo. 

Apesar de tudo, para nós, os resultados terão de 
considerar-se positivos, isto é, representam lucro, na 
medida em que consideramos ter valido a pena o 
esforço dispendido. 


Segunda / Terça / Quarta / Quinta 


Se interpretarmos bem o sentido do balanço, ad- 
vogamos que o lucro resultante do exercício, deve 
ser aplicado em exercícios futuros, devendo reverter 
na sua integralidade para a realização de novos 
artigos e números dedicados à 1.G. 


3. EM JEITO DE CONCLUSÃO 


Desejamos que o trabalho apresentado sirva de 
«leitmotiv» à participação mais actuante de todos 
aqueles que trabalham em Informática de Gestão. A 
revolução nos métodos de gestão obrigará os infor- 
máticos a uma revisão das soluções informáticas 
que têm preconizado e implementado, sendo vital a 
troca de experiências tanto no domínio teórico como 
no prático. 

Por outro lado, a evolução das tecnologias nos 
domínios materiais e imateriais, aponta para maiores 
capacidades de armazenamento e manuseamento 
da informação com custos tendencialmente mais bai- 
xos, e para uma alteração substancial do papel tradi- 
cional dos informáticos que tenderão para o desem- 
penho de tarefas mais nobres, abandonando, pro- 
gressivamente, o papel de codificadores. 

Não gostaríamos de terminar estas breves refle- 
xões sobre o trabalho encetado sem agradecermos 
a colaboração dos colegas — autores dos artigos, 
dos responsáveis dos centros e dos representantes 
nacionais dos construtores de equipamentos que 
acederam responder aos nossos inquéritos. 

Uma última palavra de agradecimento para o pes- 
soal de apoio dactilográfico, e não só, da API e «the 
last but not the least» para o Helder Coelho e José 
Cotta pelo apoio e sugestões várias. 
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PonhaVúmcérebro: à cabeça da sua empresa 


am nnGande 
-- n0SaBas 


Um microcomputador QUESTAR/M. 

Qualquer que seja o tipo e a dimensão da sua empresa, 
com um microcomputador QUESTAR/M, você tem, sem- 
pre, a solução mais adequada, mais prática e mais segura 
de todos os seus problemas de Gestão. Do processamento 
de salários à contabilidade, do controlo de stocks, à factu- 
ração, etc. : 

Sem necessidade de recorrer a um técnico especializado. 
Você ou qualquer outra pessoa pode, num curtíssimo es- 


EBIT .. 


Rua Sarmento de Beires, n.º 39, loja C 
1900 LISBOA 
Telefs.: 8056 46 - 80 57 46-80 58 46 - 80 56 96 - 8057 96 


paço de tempo, aprender a utilizar um microcomputador 
QUESTAR/M com a maior facilidade e total rentabilidade. 
Com a segurança que a Cil Honeywell Bull, um dos maio- 
res construtores mundiais de computadores, instalado em 
Portugal há mais de 25 anos, lhe pode garantir. 

Agora, o dinamismo e crescimento da sua empresa estão 
na sua mão. Com um microcomputador QUESTAR/M, a 
informática profissional e Você, estão sempre no centro da 
acção. 


(= e qu SS A A O O O O SS O 


Queiram enviar-me informações detalhadas 
sobre os microcomputadores Questar/M. 


Nome 

Posição 
Empresa 
Morada 


Localidade 
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SISTEMAS E MÉTODOS 


DE CORGANIZAÇÃO) 
E INFORMÁTICA, S.A.R.L. 


Somos uma empresa dinâmica que trabalha em Portugal, Moçambique e Angola, para o 


estado, autarquias locais. empresas e instituições diversas. 


Com uma equipa de mais de uma centena de colaboradores, constituímos um conjunto 


de especialistas de elevada e reconhecida capacidade. 


Garantimos experiência, especialização, criatividade e adequação às realidades 
e exigências dos clientes. 


Temos serviços de qualidade ao seu dispór. 
CONSULTE-NOS. 


ORGANIZAÇÃO E GESTÃO 
e Organização administrativa e financeira 
e Organização da produção 
º Racionalização de procedimentos 
e Sistemas integrados de gestão 


ESTUDOS DE DESENVOLVIMENTO 
e Desenvolvimento integrado 
e Planeamento e gestão urbana 
e Estudos sócio-económicos 
e Estudos sócio-culturais 


ESTUDOS TÉCNICO-ECONÓMICOS 
e Estudos de viabilidade 
e Projectos de investimento 
e Estudos de financiamento 
e Estudos tarifários 


INFORMÁTICA 
e Estudos de sistemas e equipamentos 
e Análise e programação 
e Packages e processamentos 
e Soluções locais sobre 
microcomputadores 


RECRUTAMENTO E SELECÇÃO 
e Análise de funções 
e Aplicação de provas técnicas 
e de aptidão 
e Classificação profissional 


FORMAÇÃO 
e Planeamento e. implementação 
de acções de formação 
e Cursos de aperfeiçoamento 
profissional 


COMUNICAÇÃO E DIVULGAÇÃO 
e Sistemas de Comunicação 
e Audiovisuais e exposições 
e Tratamento gráfico de publicações 
e Estudos de opinião 


GESTÃO DE EMPREENDIMENTOS 
e Estudos de optimização 
e Coordenação geral 
e Assessoria jurídica 
e Assistência técnica 


* ESCRITORIO NA REPUBLICA POPULAR 


e ADMINISTRAÇÃO, DEPARTAMENTOS ADMINISTRATIVO- 
-FINANCEIRO/ORGANIZAÇAO/ESTUDOS 
Rua da Beneficencia. 229-2.º e 3.º 1600 LISBOA 
Telex 15358 SISMET P Telefs 7637 01-76 0839-7345 22 


e DEPARTAMENTO DE INFORMATICA 
Av. Santos Dumont, 50 1000 LISBOA Telef. 731460 
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C.P. 2906 MAPUTO 

Telex 0992 6-349 ICEMO MO Telef. 22417 


e CORPO TECNICO PERMANENTE NA REPUBLICA 
POPULAR DE ANGOLA 
C.P. 10789 LUANDA Telef. 36213 
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A gestão de terceiros. 
Uma aproximação 
pelas bases de dados 


RESUMO Sendo as relações com terceiros 
peça importante numa boa gestão de 
Empresa, procurámos abordá-la de 
forma a que o tradicionalismo com 
que se costumam tratar estas coisas 
fosse ultrapassado. 

De facto, só com a informação per- 
manentemente disponível e actuali- 
zada é possível, hoje em dia, fazer 
face com êxito aos muitos proble- 
mas de gestão. A Informática, hoje, 
fornece-nos os meios necessários 
para que isso seja possível. 

O tipo de solução que apresentamos 
(aproximação pelas Bases de Dados) 
utiliza naturalmente essas novas 
possibilidades. 


ABSTRACT We haven't made a traditional appro- 


ach because third party relations are 
one of the most important matters in 
management. 

Management problems now-a-days 
needs an up-to-date and available 
data. Now-a-days, data processing 
tools make it possible. 

Our solutions — DATA BASES AP- 
PROACH — uses these new tools. 


1 — INTRODUÇÃO 


Verificamos desde há muito que parte importante 
do conteúdo da «Revista de Informática», da «nos- 
sa» revista, se encontra divorciado da maioria dos 
seus leitores. Isto é, grande parte dos artigos aí 
escritos, pese embora a qualidade e pertinência qua- 
se sempre presentes, não dizem respeito senão a 
um sector francamente minoritário e perfeitamente 
localizável no nosso panorama informático. Aliás, o 
mesmo se poderá dizer de outras manifestaçães de 
carácter informático que tiveram lugar em Portugal 
(1.º e 2º Congresso Português de Informática e 
«Sessão de Quinta-feira»). 

Dizendo de outra forma, assuntos considerados da 
área da chamada Informática de Gestão têm tido um 
- aparecimento que podemos considerar episódico. 
Contudo, também é verdade que para haver artigos 
necessários se torna que alguém escreva e encon- 


José Carlos Mascarenhas 
Quimigal 


Ro ao pessoas, sabe-se, tem constituído tarefa 
ifícil. 

É nesse contexto que aparece este artigo. Ele 
procura, portanto, levar até aos colegas informáticos 
e, porventura, a indivíduos com outros tipos de for- 
mação mas situados «por dentro» dos problemas 
empresariais, a formulação de um problema com 
que todas as organizações se debatem, ainda que a 
dimensão e estrutura das mesmas determinem o seu 
grau de complexidade. Trata-se da «Gestão de Ter- 
ceiros» cuja proposta de solução aqui apresentada 
tem uma aproximação pelas Bases de Dados. 

Dada a heterogeneidade da estrutura empresarial 
existente, procuráâmos que o exemplo aqui exibido, 
embora necessariamente teórico, contemplasse as 
necessidades eventuais de um bom número das 
nossas realidades empresariais (muitas delas atra- 
vés de um tratamento bem mais simples). Daí, a 
relativa complexidade da estrutura concebida. 

Considerámos pertinente a divisão do trabalho em 
duas partes distintas, servindo a primeira para a 
apresentação do tipo de organização pretendido 
suas principais características, objectivos a atingir, 
âmbito do projecto e tipo de solução informático pre- 
conizado, e a segunda para se focar, necessaria- 
mente de forma sumária dadas as características do 
artigo, aspectos vários da construção da estrutura 
lógica dos dados que servirá de suporte ao sistema, 
o porquê de uma aproximação pelas Bases de Da- 
dos a um problema deste género, as razões de uma 
opção determinada face a outra ou outras alternati- 
vas, etc.. 

Nas diversas partes do trabalho apenas serão 
apresentados os aspectos organizacionais e informá- 
ticos indispensáveis a uma boa compreensão do que 
pretendemos trasmitir. 

Não gostaríamos de terminar estas notas introdu- 
tórias sem dizer que o exemplo aqui apresentado 
não pretende ser mais do que isso mesmo. E, ape- 
nas, uma contribuição.Não será a única nem talvez a 
melhor. Diremos, no entanto, que ela se nos afigura 
uma forma exequível para a resolução de problemas 
numa área bem sensível dentro de uma gestão que 
se quer profíqua. 


2 — ENQUADRAMENTO DO PROBLEMA NA 
EMPRESA 


2.1 — À estrutura 
A empresa, que designaremos por ABC, criada 


Fios o trabalho apresenta a estrutura seguinte 
ig. 1): 
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a gestão de terceiros 


DIRECÇÃO 
x 
(OPERAC, ) 


SERVIÇOS 
ADMINISTRA 
TIVOS 


NEGOCIO 1 


Dado o nulo interesse que teriam, não se atrituí- 
ram nomes às direcções e negócios. Assim, desig- 
nar-se-ão, respectivamente, por Direcção X e Direc- 
ção Y e Negócio 1, Negócio 2 e Negócio 3. 

Trata-se de uma empresa que se dedica ao fabri- 
co e comercialização de vários produtos. Estes, de 
acordo com as suas características, estão agrupados 
em negócios. Por necessidade de comercialização, 
dois deles (Negócio 1 e Negócio 2) estão submeti- 
dos a uma mesma direcção (Direcção X) estando o 
outro negócio (Negócio 3) dependente de uma se- 
gunda direcção (Direcção Y). Estas direcções serão 
referidas no decorrer do trabalho como Direcções 
Operacionais. 

Dos restantes sectores da empresa interessa des- 
tacar, pela sua importância, as «Direcção Adminis- 
trativa e Financeira» e «Direcção de Organização e 
Informática». A primeira tem, entre outras, as tarefas 
de consolidação das operações efectuadas por cada 
uma das direcções operacionais, entre as quais se 
encontram, naturalmente, as englobadas na «Gestão 
de Terceiros». A segunda, tem a seu cargo o trata- 
mento de todos os dados e o fornecimento seleccio- 
nado da informação aos mais diversos sectores e 
níveis da empresa. Entenda-se, no entanto, que todo 
o trabalho de recolha/validação e a obtenção de 
significativo volume de informação deverá ser pro- 
cessado directamente pelos utilizadores. Mais à 
frente voltaremos a este assunto. 


2.2 — Os objectivos 


Atingir determinados objectivos fixados é uma das 
preocupações constantes dos diversos órgãos deci- 
sores e, afinal, a razão de ser de qualquer projecto, 
seja ele referente à «Gestão de Terceiros» ou a 
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ADMINISTRA ||ADMINISTRAT 
TIVOS CENTRAIS 


SERVIÇOS 


CONTABI- CONTABI- CENTRO 
LIDADE LIDADE DE 
CENTRAL INFORMÁTICA 


outra área da empresa. Vejamos o caso presente: 

Os objectivos podem ser situados a dois níveis: 
gerais ou globais e específicos. No primeiro nível 
serão de considerar os seguintes: 


— Melhoria da Gestão de Terceiros através de 
uma informação permanentemente disponível e 
actualizada. 

— Maior adaptabilidade e flexibilidade do sistema 
de informação. 

— Maior operacionalidade. 


No segundo nível, mais directamente relacionado 
com cada realidade empresarial, podemos citar, com 
um relativo ênfase para o aspecto contabilístico/fi- 
nanceiro, alguns que julgamos importantes para uma 
gestão «em cima». Assim, temos nomeadamente: 


— Individualização rigorosa de cada terceiro 

— Validação imediata e segura 

— Saldos de clientes e/ou fornecedores perma- 
nentemente actualizados 

— Consolidação permanente 

— Melhoria da relação prazos de cobrança/prazos 
de pagamento 

— Hierarquização de clientes e fornecedores 

— Controlo na concessão de crédito 

— Maior facilidade na execução de orçamentos de 
tesouraria 

— Selecção adequada da informação segundo os 
sectores e níveis da empresa. 


2.3— O projecto 


Até aqui tivemos oportunidade de transcrever as- 
pectos relacionados com a empresa, naquilo que 
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são as suas características gerais e objectivos. 

É, todavia, através das múltiplas tarefas desenvol- 
vidas e a desenvolver (projectos) nas diversas áreas, 
que as deficiências podem ser supridas e os objecti- 
vos atingidos. Na que procurámos abordar, e com 
vista aos objectivos fixados, há que desenvolver um 
projecto que o possibilite. E o que faremos a seguir. 

Em primeiro lugar, o projecto deverá ter em conta 
a existência de um determinado conjunto de procedi- 
mentos administrativos e de fluxos de informação 
entre os vários sectores da empresa e é nessa reali- 
dade que se terá de desenvolver (considera-se, para 
simplificar, que aspectos como, organização de ser- 
viços, racionalização de circuitos e outros do âmbito 
da organização, não necessitam de quaisquer ajus- 
tamentos). 

Em termos esquemáticos e de forma genérica, os 
fluxos de informação podem ser representados da 
seguinte forma (Fig. 2): 
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FIG. 2 


Por outro lado, o âmbito do projecto deverá ser 
considerado a dois níveis: 

— Entidades 

— Áreas de Informação. 

Comecemos pela primeira. As entidades utiliza- 
doras envolvidas directamente no projecto (com indi- 
cação do seu grau de envolvimento), já que indirec- 
tamente existem várias outras que beneficiam da 
informação obtida, são (Fig. 3): 
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FIG. 3 
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No que respeita às áreas de informação, abrange- 
mos com o projecto aquelas que, das partes inte- 
grantes da gestão de terceiros, são, na nossa opi- 
nião as mais importantes. Não constituiu, assim, 
nosso objectivo a tentativa de uma cobertura exaus- 
tiva desta área da gestão. 

O esquema que a seguir apresentamos repre- 
senta, a nosso ver bem, as diversas áreas de infor- 
mação que o projecto pretende cobrir e em que 
medida o faz. Por outro lado, estão também repre- 
sentadas algumas áreas que não foram consi- 
deradas. 

Assim, teremos (Fig. 4): 


O) NÃO ABRANGIDO 


FIG. 4 


2.4 — A solução informática 


Finalizamos este capítulo com a apresentação da 
solução informática que julgámos boa para uma im- 
plementação com êxito. 

Essa solução baseia-se no conceito de informática 
distribuída, a qual se mostra bastante eficaz na sa- 
tisfação das necessidades de um trabalho deste gé- 
nero e da estrutura da empresa que lhe está asso- 
ciada. Ela permite, simultaneamente, levar a informá- 
tica até junto dos utilizadores finais através de termi- 
nais de consulta/actualização aí colocados, contri- 
buindo, assim, para a tão necessária desmistificação 
da informática, e uma centralização de meios, a 
qual, além de outras vantagens, permite uma con- 
solidação permanente e disponível aos diversos ór- 
gãos centrais. 

É claro que esta solução, tal como qualquer outra, 
tem alguns aspectos mais favoráveis que outros e, 
mesmo, algumas desvantagens. 

Como pontos favoráveis apontamos os seguintes: 


— Cobertura das necessidades de informação 

— Recolha/validação simultâneas 

— Acesso à informação em «tempo real» 

— Acesso à informação por simples consulta de 
terminais 

— Solução de acordo com a arquitectura dos equi- 
pamentos da moderna geração 

— Hardware e Software básico potentes 

— Minimização dos problemas de crescimento 

— Informação consolidada permanentemente dis- 
ponível e actualizada. 


Como factores menos favoráveis ou mesmo des- 
vantajosos enunciamos os seguintes: 
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— Necessidade de formação/reconversão do pes- 
soal administrativo 

— Partilha de um computador central com outros 
utilizadores 

— Dependência da Direcção de Organização e In- 
formática quanto à gestão de meios informáti- 
cos (humanos e técnicos) 

— Carência de um fluxo regular e contínuo de 
documentos. 

— Necessidade eventual de recurso às telecomu- 
nicações, o que no nosso país é, por vezes, 
preocupante. 


Graficamente, esta solução pode apresentar-se do 
seguinte modo (Fig. 5): 


Sia) 2) 


FIG, 5 


O que atrás se refere, devemos notá-lo, não é 
mais do que um exemplo teórico e, portanto, não é 
nem pretende ser padrão para quaisquer aplicações 
no campo real. Neste, a cada caso concreto corres- 
ponderá, necessariamente um estudo adequado. 

O estudo deverá, na nossa opinião, ser efectuado 
numa perspectiva organizacional, ou seja, fazendo- 
-se uma aproximação ao problema (supõe-se, evi- 
dentemente, que este tenha a dimensão e complexi- 
dade adequadas), tendo por base o próprio sistema 
de gestão que se pretende implementar. Este mé- 
todo exige, como facilmente transparece, uma forte 
participação dos utilizadores na concepção do sis- 
tema de gestão pretendido. 

Deve-se evitar, portanto, abordar as questões de 
uma forma «informaticista», isto é, não visando, 
como acontece na maior parte dos casos, mais do 
que uma mudança no tipo de tratamento deixando 
por analisar eventuais carências de base no próprio 
sistema de informação. 


3 — A GESTÃO DE TERCEIROS. UMA PRO- 
POSTA DE SOLUÇÃO 


3.1. — As características do problema 


Como considerações a fazer, já que outras ha- 
veria, sobre o projecto, escolhemos duas que reputa- 
mos de fundamentais. Primeiramente a caracteriza- 
ção geral do sistema a implementar, tipos de trata- 
mento e principal informação a fornecer. Em se- 
gundo lugar a definição e caracterização do terceiro 
num tipo de empresa como aquela que aqui se apre- 
senta. 

Assim, no que respeita à primeira, e se bem que 
já na primeira parte deste trabalho tivéssemos des- 
crito quais os objectivos, gerais e específicos, não 
mencionámos, contudo, qual o sistema de informa- 
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ção a produzir de modo a atingi-los. 

E natural que no âmbito de um artigo como este, 
que tem como preocupação fundamental a apresen- 
tação de um problema e não o seu tratamento 
exaustivo, não façamos mais do que apontar algu- 
mas pistas, algumas chamadas de atenção, que de 
algum modo possam ajudar numa eventual aborda- 
gem concreta no seio de uma empresa. 

Uma primeira questão que se poderá colocar é 
qual o tipo de informação a tratar, ainda que se 
saiba as variações que existem de empresa para 
empresa. A questão é legítima por pensarmos que 
existem tipos de tratamentos de informação comuns 
às várias empresas mesmo que estas pertençam a 
sectores bem difirentes. 

O esquema que a seguir apresentamos (Fig. 6) 
ilustra uma forma da divisão do trabalho na gestão 
de terceiros: 

Como se vê, são criadas duas grandes áreas a 
que chamamos, respectivamente: 


— Tratamento Sistemático ou Periódico 
— Tratamento não Sistemático ou A Pedido 


Na primeira, para além do trabalho diário da movi- 
mentação (recolha/validação/actualização) de docu- 
mentos e dos trabalhos de identificação, é englo- 
bada a componente «batch» do sistema. É nela que 
se consubstancia toda a informação de carácter con- 
tabilístico e de gestão que periodicamente a empre- 
sa necessita para a sua manutenção como tal nas 
diversas áreas e aos vários níveis. 

Como exemplos deste tipo de informação pode- 
mos pontar balancetes, análises e hierarquização de 
clientes, extractos de conta, relações de letras a 
receber/a pagar, análises de antiguidade de saldos e 
limites de crédito, análise quanto à distribuição geo- 
gráfica, análise de preferências, etc.. 

Por outro lado, naquilo que designamos por «Tra- 
tamento Não Sistemático ou A Pedido» é englobada 
toda a informação cuja actualidade/disponibilidade é 
indispensável e que o acesso a terminais permite 
obter a qualquer momento. Este é, aliás, um aspecto 
nuclear para se atingir os objectivos descritos. É, no 
fim de contas, aqui que reside o salto qualitativo 
(que a evolução informática permite) na contribuição 
da informação para uma boa gestão de terceiros ou, 
por outras palavras, é a disponibilidade permanente 
de uma informação actualizada que permite uma 
gestão «em cima». 

No entanto, também é necessário dizer, que a 
operacionalidade do sistema poderá ser posta em 
causa se existir uma situação de indisciplina quanto 
à preparação dos documentos para tratamento infor- 
mático. A não existência de um fluxo regular e contí- 
nuo de documentos, inviabilizará, por certo, a con- 
sulta de elementos de informação actualizados, além 
de eventuais «engarrafamentos» na recolha. 

Deste modo, e dadas as características da empre- 
sa, a informação disponível deverá satisfazer neces- 
sidades de gestão quer a nível das direcções opera- 
cionais, quer a nível dos órgãos centrais. 

Na informação direccionada especificamente às 
necessidades de gestão das direcções operacionais 
destacamos: 


— Saldo de cliente/fornecedor/outros ao nível da 
conta 

— Relação de documentos em dívida (activas ou 
passivas consoante os casos) de cada cliente/ 
fornecedor tomados ao nível da conta 

— Extracto de conta-corrente de cliente/fornecedor 
tomado ao nível da conta 
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FIG. 6 


— Informação detalhada sobre letras nos seus 
mais diversos domínios 

— Saldo de cliente/fornecedor/outros aos diversos 
níveis da Direcção (mercado, negócio). 

— Saldo consolidado do terceiro ao nível da direc- 
ção (esta consolidação poderá adquirir-se, tam- 
bém, em termos mais analíticos como por 
exemplo no negócio). 


Por outro lado, no que respeita aos órgãos cen- 
trais, algumas das suas necessidades de gestão po- 
derão ser satisfeitas pelas seguintes informações: 


— Saldo de cada cliente/fornecedor/outros em 
cada direcção operacional . 

— Saldo consolidado do terceiro em cada direcção 
operacional 

— Saldo consolidado do terceiro face à empresa 


Para finalizar este ponto, precisemos um pouco 
mais dois aspectos relacionados com o anterior- 
mente dito. O primeiro tem a ver com a natureza do 
saldo apresentado. Este deverá individualizar, sem- 
pre, os diversos tipos de saldo possíveis. A título de 
exemplo poderemos mencionar «saldo de conta- 
-corrente» e «saldo de c/letras e outros títulos a 
receber». 

Finalmente o segundo aspecto refere-se ao pro- 
blema do acesso à informação. Entendemos que se 
deverá prever sempre, com maior ou menor flexibili- 
dade, o acesso das diversas entidades à informação. 
Tal é possível, como se sabe, mediante um esque- 
ma de segurança informáticas que previrá quem e 
em que condições poderá ter acesso a esta ou 
àquela informação. 

A segunda questão fundamental é, como disse- 
mos, a definição e caracterização do terceiro, enti- 
dade com a qual a empresa mantém relações co- 
merciais e que é o objecto deste trabalho. 
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As considerações que se seguem abrangerão o 
terceiro segundo os três pontos seguintes: 


— Identificação do Terceiro 
— Características do Terceiro 
— Individualização do Terceiro 


A identificação rigorosa do terceiro é o aspecto 
crucial de todo o projecto. Há, portanto, que obser- 
var os cuidados necessários. A nosso ver, poderão 
mencionar-se: 


— Existência de um único código por terceiro para 
toda a empresa. 

— Atribuição de códigos de terceiro por um único 
serviço dentro da empresa, numa primeira fase. 

— Localização do serviço atribuidor de códigos 
fora das direcções operacionais, igualmente 
numa primeira fase. 

— Numa segunda fase, atribuição descentralizada 
com recurso a meios informáticos. 


Em relação ao primeiro, ou seja à existência de 
um único código de terceiro em toda a empresa 
podemos dizer que é a sua própria natureza e fun- 
ções que assim o exigem. Não devemos esquecer 
que ele constitui a única possibilidade de individuali- 
zação rigorosa de um terceiro. 

Também é verdade, todavia, que tal exigência le- 
vanta dificuldades de operacionalidade. Assim, po- 
derá perguntar-se como articular os diversos sec- 
tores da empresa, dado que é pressuposto cada 
direcção operacional ter em cada negócio autonomia 
significativa na sua política comercial e, portanto, na 
sua relação com terceiros. 

Como sustentamos que um terceiro, independen- 
temente do número de contas abertas na empresa 
na sua qualidade de cliente/fornecedor/outros deve- 
dores e credores, deverá possuir apenas um código 
que o identifique perante todos, o problema acima 
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mencionado deverá ser ultrapassado no âmbito do 
princípio estabelecido. 

Assim, e para uma organização cujas característi- 
cas internas não lhe permitam passar directamente à 
segunda fase, existirá uma primeira na qual haverá 
um único órgão em toda a empresa responsável 
pela atribuição de códigos de terceiro e situado fora 
do âmbito das direcções operacionais. 

Um único órgão atribuidor de códigos pode justifi- 
car-se facilmente por razões de coerência e de se- 
gurança. Estar fora do âmbito das direcções opera- 
cionais justifica-se pela relação directa que qualquer 
delas tem com o assunto e para os perigos de 
redundância e outros que daí podem resultar. 

Com os princípios definidos haverá que criar um 
circuito administrativo eficaz que dê resposta ao sis- 
tema e, consequentemente, ao problema de articula- 
ção acima levantado. 

Aquando do aparecimento de um novo terceiro (as 
direcções devem ter ao seu dispor meios que lhes 
permitam verificar quais os terceiros existentes) os 
serviços deverão enviar ao sector responsável pela 
atribuição de códigos um documento (chamemos-lhe 
«Documento de Identificação») onde constarão todos 
os elementos necessários a uma identificação cor- 
recta. Será de grande utilidade a existência de nor- 
mas quanto ao preenchimento de nomes, moradas, 
etc. Por exemplo, as siglas serem apostas sempre 
antes da firma ou denominação social da empresa, 
determinadas abreviaturas serem feitas sempre da 
mesma maneira, etc. 

Temos assim que o primeiro lançamento na base 
de dados referente a um terceiro é o correspondente 
à identificação e é efectuado pelo sector responsável 
pela atribuição de códigos de terceiro na empresa. 
Após o lançamento, o documento de identificação, 
agora já preenchido na totalidade; é devolvido à 
entidade respectiva. 

Numa segunda fase, ou imediatamente se as con- 
dições o permitirem, pode avançar-se para formas 
mais sofisticadas. Neste caso, e no ambiente da 
informática distribuída que é o deste trabalho, a atri- 
buição de códigos de terceiro faz-se descentralizada- 
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mente no seio das próprias direcções operacionais. 

Esta atribuição é feita automaticamente recorrendo, 

como é natural, a um algoritmo determinado. 
Finalmente devemos dizer que, sendo esta uma 


“das áreas contempladas no projecto, será de tê-la 


em conta aquando da construção da base de dados. 

O segundo ponto focado — Características do 
Terceiro — tem a ver com as características da 
empresa apresentada. Se para muitas o conceito de 
terceiro se confunde com o de cliente ou com o de 
fornecedor, neste caso tal não acontece. Aqui, um 
terceiro pode apresentar características várias con- 
soante a forma como se apresenta (cliente e/ou for- 
necedor, etc.) perante a empresa. 

Recorrendo à forma esquemática, apresentamos a 
seguir um quadro (FIG 7) onde se pode visualizar as 
diversas «caras» que um terceiro pode apresentar. 

Deste modo, qualquer movimento a lançar neces- 
sita de algo mais do que o código de terceiro para 
uma individualização correcta — terceiro ponto apre- 
sentado — o que quer dizer que qualquer docu- 
mento a lançar deverá conter a seguinte estrutura de 
códigos: 


XXXXX.XX.XX.X.X 


Código de Tipo de Terceiro 
Código de Mercado 
Código de Negócio 
Código de Direcção 
Código de Terceiro 


A codificação dos vários elementos da estrutura, 
exceptuando o código de terceiro de que já falámos, 
são, em princípio, atribuídos uma só vez para toda a 
empresa não apresentando quaisquer dificuldades. 

Poder-se-á objectar dizendo que se trata de uma 
estrutura «pesada» tendo em conta os eventual- 
mente muitos documentos a lançar. Se o problema 
for encarado de forma simplista partilharemos dessa 
convicção. Contudo, pensamos que, olhando-o de 
outra forma, a questão pode ser francamente minimi- 
zada. Uma forma simples de o conseguir, haverá 
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outras, consistirá em se proceder sistematicamente à 
preparação prévia da documentação a lançar. Se por 
exemplo se agruparem os documentos segundo os 
tipos de terceiro, direcções, negócios, mercados e 
códigos de terceiro, um simples sistema de «menus» 
pemitirá uma grande poupança de tempo e trabalho. 
Isto é, um encadeamento de «menus» implicará que 
a digitação dos diversos membros da estrutura de 
códigos se torne necessária apenas quando da mu- 
dança para membros respectivos diferentes. 


3.2 — O MODELO DE DADOS 


Eis-nos chegados ao ponto crucial do nosso traba- 
lho. Daqui em diante será nossa preocupação falar- 
mos das técnicas que, em face do problema posto, 
julgámos pertinente propor para a sua resolução. 
Essa nossa proposta assenta, como se sabe, numa 
abordagem pelas bases de dados. Porquê? É o que 
tentaremos explicar de seguida. 

Como é do conhecimento geral, as bases de da- 
dos, «grupos de dados interrelacionados, armazena- 
dos conjuntamente, sem redundâncias nocivas ou 
desnecessárias e de modo a servirem múltiplas apli- 
cações» (Martin, 7., 1977), surgiram como uma alter- 
nativa poderosa «aos ficheiros clássicos» típicos da 
época do «batch». Elas trouxeram, em relação âque- 
les, vantagens muito significativas das quais desta- 
camos: 


— Independência dos dados face aos programas 
— Maior consistência 

— Ausência de redundâncias 

— Menores custos de manutenção 


Embora estas características sejam na generali- 
dade aceites, há que focar algumas nuances. Em 
relação ao terceiro aspecto sabemos que por vezes 
existe vantagem em admitir alguma redundância 
pelo que aquela afirmação deve ser entendida como 
característica geral. Por outro lado, também os me- 
nores níveis de manutenção nem sempre são atingi- 
dos. Num estudo relativamene recente, no âmbito da 
CEE, sobre avaliação e implementação de sistemas 
de bases de dados na Europa, chegou-se à conclu- 
são, face às empresas consultadas, não se ter sen- 
tido reduções significativas nos custos de manuten- 
ção (Peeters, E., 1981). 

Face às vantagens não é líquido, contudo, que 
pelo facto das mesmas existirem, o recurso às bases 
de dados constitua regra independentemente do pro- 
blema em estudo. De facto, a utilização de bases de 
dados só deverá concretizar-se depois de um estudo 
sério do problema a resolver dado que, por vezes, 
poderá acontecer que se torne mesmo desaconse- 
lhável o seu uso. 

Outro aspecto para que chamamos a atenção, 
neste caso especial dos responsáveis, é o «environ- 
ment» sob o qual uma empresa deve enveredar 
pelas bases de dados. Um dos factores mais negati- 
vos e causadores de insucessos, como ainda recen- 
temente voltaria a ser referido na Convention Infor- 
matique, é o de sobreestimar as capacidades dos 
SGBD's e substimar os casos de impreparação téc- 
nica e humana para esse novo caminho. 

'Bom, mas âmbito do artigo não é propriamente 


tratar das condições que uma empresa deve possuir ' 


quando decide enveredar pelas bases de dados. É, 
sim o de fornecer algumas indicações sobre as fases 
a ultrapassar até chegar à estrutura lógica de dados, 
principal suporte do êxito dum projecto. 

Uma primeira nota tem a ver com o SGBD a 
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utilizar. Conhecemos as características que um bom 
SGBD deve possuir — controlo da segurança e inte- 
gridade da base de dados, independência em rela- 
ção ao equipamento e à linguagem, rendimento óp- 
timo em todos os casos, facilidades em fases de 
conversão ou transição, etc. — e os cuidados a ter 
na escolha do mesmo. Mas também sabemos que 
para muitos dos utilizadores, por condicionalismos 
vários, essa possibilidade de escolha é mais 
aparente que real. Muitas vezes (quantas o não 
serão em Portugal?), é o fornecedor do equipamento 
que existe na casa que «impõe» a utilização de um 
determinado SGBD. 

Não procurando, por isso, sofisticar a questão, o 
modelo proposto, já na sua fase de desenho interno, 
consubstanciar-se-á numa estrutura hierárquica 
tendo como gestor um SGBD francamente conhe- 
cido no mercado. 

Tratemos agora das razões que nos levam a ad- 
vogar uma solução dste tipo, ou seja, propondo uma 
aproximação pelas bases de dados. Diremos que 
são as próprias características do problema (já atrás 
mencionadas) que impõem uma solução deste gé- 
nero. De facto, fazer face às necessidades da em- 
presa através de uma abordagem tradicional (fichei- 
ros clássicos), a ser exequível, enfermaria à partida 
de graves dificuldades na sua geração e sobrevivên- 
cia como sistema. Entre outras poderíamos apontar 
as seguintes: 


pias se» apa de ficheiros extremamente com- 

plexa 

— Informação redundante em grande número 

— Esquema de seguranças bastante complexo 

— Grande deterioração de tempos de resposta 

— Manutenção bastante «pesada» 

— Subaproveitamento significativo dos recursos 
actualmente disponíveis 


Para além das características próprias, surge 
ainda um outro aspecto de natureza estratégica que 
é de realçar. Pretende-se que a informação sobre 
terceiros exista uma só vez na empresa e esteja 
disponível para tratamento no âmbito de projectos 
noutras áreas. 

Justificada a decisão, é altura de tratarmos da 
construção do nosso modelo de dados. 

Já conhecemos os objectivos, o tipo de informa- 
ção a fornecer, mas ainda não conhecemos os da- 
dos que constituem essa informação. Não sabemos, 
de igual modo, a forma, por exemplo, como deverão 
ser tratados os documentos, necessariamente de ori- 
gem e conteúdo diversos, etc. Então, como construir 
um modelo com base em elementos que desconhe- 
cemos e que são fundamentais a essa construção? 

Dado que existem vários trabalhos a efectuar, 
qualquer deles complexo, propomos a adopção de 
uma metodologia. Existem várias disponíveis cada 
qual com os seus pontos fortes e outros menos 
favoráveis. Somos daqueles que pensam (a convic- 
ção existe e é baseada), que usar uma metodologia 
é sempre melhor que não usar nenhuma. 

Para o desenvolvimento do projecto e conse- 
quente construção do modelo proposto, nosso objec- 
tivo, são de considerar várias fases de trabalho a 
percorrer metodicamente e que são as seguintes: 


— Determinação das grandes áreas do projecto 

— Decomposição de cada uma das áreas, suces- 
sivamente, até à definição de tarefas elemen- 
tares 

— Desenho dos «diálogos» para a componente 
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«tempo-real» e de toda a informação a tratar 


em «batch» 

— Desenho dos diagramas relacionais por tarefa 
de modo a estabelecer as relações lógicas en- 
tre as diversas entidades do sistema 

— Quantificação, por tarefa, de frequências e 
acessos 

— Consolidação dos diagramas relacionais até 
chegar ao diagrama final, ou seja, ao modelo 
de dados 


Numa segunda parte, e pertencendo já ao «dese- 
nho interno», proceder-se-á à construção, com base 
naquele modelo, da estrutura lógica da base de 
dados. 

Como se pode observar, o método proposto (já 
testado) assenta num envolvimento real dos utiliza- 
dores no evoluir do projecto. Estes têm, assim, a 
possibilidade de encarar, progressivamente, novas 
formas de trabalhar podendo criar mesmo cenários 
alternativos definindo, portanto, cada vez com mais 
rigor o tipo de informação que necessitam e quais as 
formas mais compensadoras de a obter. 

Exemplificando a aplicação do método e admitindo 
que as primeiras fases (as mais difíceis de explanar 
aqui) se encontram ultrapassadas, consideremos, de 
entre as diversas tarefas que compõem o projecto, 
as duas seguintes, aliás bastante simples: 


— Saldos de Terceiro Face à Direcção (consultas) 
— Movimentos de Clientes a Débito (movimen- 
tação) 


Suponhamos, ainda, que se definiria como desejá- 
vel a inclusão de determinado conjunto de informa- 
ções em acada uma delas e que essas informações 
seriam, por exemplo, as seguintes (de output e de 
input, respectivamente): 


1) Para a tarefa «Saldos de Terceiro Face à 
Direcção» 

— Código de terceiro 

— Nome do terceiro 

— Morada do terceiro 

— Saldos de cliente face à direcção (c/cor- 
rente e c/letras) 

— Saldos de fornecedor face à direcção (c/ 
corrente e c/letras) 

— Saldos de terceiro face à direcção (c/cor- 
rente e c/letras) 


2) Para a tarefa «Movimentos de Clientes a Dé- 
bito» 
— Código de terceiro 
— Código de direcção 
— Código de negócio 
— Código de mercado 
— Designação do documento a lançar 
— Número do documento a lançar 
— Data do documento a lançar 
— Valor do documento a lançar 


NOTAS — Para lá dos dados de entrada são de 
considerar, quer os dados de identifica- 
ção quer os acumulados diversos que 
necessariamente são actualizados. 

— Não se torna necessária a inclusão nos 
dados de entrada do código do tipo de 
terceiro dado que é a própria transacção 
que deve definir, com maior ou menor 
flexibilidade, o tipo de movimentos a in- 
cluir nela. Aliás, o próprio título da tran- 
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sacção que escolhemos é bem elucida- 
tivo. 


Utilizando uma simbologia conhecida. 


ENTIDADE RELAÇÃO LOGICA ATRIBUTO 


os diagramas relacionais apresentar-se-iam, para 
cada tarefa, da forma seguinte: 


1) Para a tarefa «Saldos de Terceiro Face à 
Direcção» (FIG 8) 
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DIRECÇÃO 
AC. CRED, 
(ME. RED. pp lemd CLIENTE 
FORNECED. 
TERCEIRO AC, CRED. 
CLIENTE 
ACUM, LET 
ã MENA A REC, 
AC. DES. 
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SOTA: OS SALDOS SÃO OBTIDOS POR SOMA ALGEBRICA DOS RESPECTIVOS ACUMULADOS 


FIG. 8 


2) Para a tarefa «Movimentos de Clientes a Dé- 


bito» (FIG 9) 
seo = nEcósis ) negando 
pausas pr TOS É N DIRECÇÃO 


x p= 

AC, DEB. 
BIO | 
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Donde resultaria como diagrama de consolidação 
de tarefas (FIG 10): 


INFORMÁTICA 


OD 
& 


TERCEIRO 


AC, CRED, 


OUTROS ) 


AC, DEB, 
+ FORNECED, 


ACUM, 
LET. A PAG 
AC, CRED. ACUM, 
VLET. A PAG 


CLIENTE 


AC. CRED, 
FORNECED, 


AC. DEB, 
CLIENTE 


TERCEIRO/ 
/DIRECÇÃO 


TIPO DE 
TERCEIRO 


CÓDIGO 
TIPO TERC. 


TIPO DE 
TERCEIRO 


ACUM, 
DEBITO 


FIG. 10 

Se agora procedessemos, neste último diagrama, 
à quantificação de frequências e acessos, ficaríamos 
em presença do modelo de dados num universo 
composto pelas duas tarefas apresentadas. 

Para o projecto, sabendo que o tipo de tarefas 
diferirá de empresa para empresa consoante a com- 
plexidade do problema em cada uma delas, julgá- 
mos pertinente, no entanto, apresentar um modelo 
possível que se baseia numa escolha das tarefas 
mais significativas e correntes de um projecto deste 
tipo enquadradas, naturalmente, na caracterização 
que atrás tivemos oportunidade de efectuar. 

Deste modo, o modelo de dados para o projecto 
apresenta o seguinte aspecto (FIG 11): 
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FIG. 11 
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3.3— A estrutura lógica da base de dados 


Como já tivemos oportunidade de dizer, é com 
base no modelo de dados que podemos construir a 
estrutura lógica da base de dados que, neste caso, 
se apresenta de forma hierarquizada. 

A estrutura a que chegámos tem a forma seguinte 
(FIG 12): 


TERCEIRO 


Sobre esta estrutura várias questões se poderão 
colocar uma vez que ela mais não é do que o 
corolário do modelo concebido, o qual, por sua vez, 
traduz uma série de opções feitas ao longo do de- 


Dada a sua variabilidade não se apresentam os senho. 


atributos inerentes a cada entidade/relação lógica. 
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De entre várias, e condionados pela exiguidade de 
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espaço que um artigo impõe, destacamos uma que 
julgamos importante e de realce imediato. 

À questão prende-se com qualquer informação 
que se pretenda, de carácter intermédio, isto é, qual- 
quer consulta a nível de Direcção/Negócio obriga a 
uma pesquisa sequencial na base de dados ao nível 
respectivo, ao necessário somatório das ocorrências 
e, finalmente, à visualização dos elementos pretendi- 
dos. Daqui resulta, obviamente, a degradação do 
tempo de resposta e, por inerência, uma deficiente 
utilização dos recursos. 

A preocupação é legítima e permite mostrar que a 
construção de um modelo de dados não é uma 
questão pacífica em que se percorre mais ou menos 
sistematicamente as fases apresentadas por uma 
determinada metodologia até se chegar ao modelo 
final. Pelo contrário, em todas as fases torna-se ne- 
cessário ponderar as decisões de acordo com o 
projecto que se pretende implementar. 

A título de exemplo, e no que respeita directa- 
mente ao problema acima formulado, acessos direc- 
tos em consultas ao nível de Direcção/Negócio obri- 
garia a prever entradas na base segundo aqueles 
códigos. Esta possibilidade implicaria o aparecimento 
de várias bases de dados com as correspondentes 
relações lógicas entre elas, o que tornaria obrigatório 
que em cada movimento de terceiros que se efec- 
tuasse (facturação, recebimentos, pagamentos, sa- 
ques, aceites, etc.) se tivessem de actualizar todas 
as bases de dados existentes. Quer dizer, para per- 
mitir um acesso directo em questões cuja frequência 
é mais ou menos irrelevante em termos de projecto, 
iríamos obrigar o sistema ao estabelecimento de 
acessos entre diversas bases de dados em transac- 
ções dezenas de vezes mais frequentes. 


4 — CONCLUSÕES 


Em jeito de conclusão, repetimos o que dissemos 
no início. Procurámos formular uma questão familiar 
às empresas Para muitas delas o problema estará 
resolvido ou a sua dimensão não justificará um tipo 
de abordagem tão sofisticado. Cremos, no entanto, a 
nossa experiência prática demonstra-nos isso, que 
existirão também algumas nas quais alguns dos pon- 
tos que tratámos e das sugestões que fizemos po- 
derão ter alguma aplicabilidade. Neste aspecto, está 
nos órgãos decisores intermédios, muitas vezes, a 
capacidade de resposta necessária. 

Que o artigo possa ter aguma utilidade é o nosso 
objectivo. Conseguimo-lo? Têm a palavra os leitores. 
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Áreas para comunicações técnicas: 
— Demonstração de teoremas 
— Programação automática 


— Modelação cognitiva 
— Sistemas periciais 
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— Aprendizagem e aquisição do conhecimento 
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— Planeamento e procura 
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um computador e ... 


Desta definição do dicionário conclui-se que o computador é uma 
máquina. 


A característica de qualquer máquina é a de apenas poder executar 
as tarefas para as quais foi concebida e fabricada, por mais complicadas 
que estas sejam. 


A «inteligência» de um computador é uma invenção romanesca ou 
cinematográfica. 

De facto ele apenas transforma uma matéria-prima — os dados dum 
problema, num produto acabado, — resultados, automaticamente, ou seja 
sem intervenção humana, tal como o dicionário o diz. 


O computador age por delegação dum poder estritamente humano, 
poder esse que cada vez mais e melhor sabe tirar partido da mais 
original das máquinas inventadas pelo homem no século XX. 


A IBM despende grande parte do seu potencial humano e financeiro 
na investigação, desenvolvimento de projectos e aperfeiçoamento destas 
máquinas, que contribuem para uma melhoria das condições de vida 
das populações em todo o mundo. 
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- SEM ADJE o 
DÃO HA AMANHÃ 


o 


Na informática, como em tudo, foi a experiência de ontem que 
deu origem à metodologia actual e serão os processos de hoje 
que originarão os novos métodos de amanha. 

Sem ontem não haveria hoje e sem hoje não pode haver 
amanha! 

Ontem, era a fita perfurada; hoje as cassettes, os discos e as 
bandas; amanhã processos ainda mais evoluidos. Serão, po- 
rém, os conhecimentos de hoje que darão ao Homem a possi- 
bilidade de criar a metodologia do futuro. 


A informática, como técnica e como ciência, é, também, 
uma das áreas de actuação da Livraria Escolar Editora; 
dispõe, por isso, da mais completa e actualizada biblio- 
grafia sobre o assunto. E: 


LIVRARIA ESCOLAR EDITORA - 


A livraria técnica e científica do Pais 
Lisboa— Rua da Escola Politécnica. 80-A - Telef. 66 40 40 - 1200 LISBOA 
Porto — Rua da Boa Hora. 43 - Telef. 38 27 86 - 4000 PORTO 
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Gestão de Pessoal 


RESUMO Este trabalho tem como objectivo 
caracterizar a função pessoal num con- 
ceito de gestão integrada e perspecti- 
var toda a problemática gestão/infor- 
mação num desenvolvimento aplicacio- 
nal capaz de superar os tradicionais 
problemas/limitações das aplicações 
de pessoal feitas à medida de cada em- 
presa e das próprias packages existen- 
tes no mercado português. Embora o 
trabalho gravite à volta do sector ban- 
cário, os conceitos apresentados, pela 
universalidade da função, aplicam-se a 
todos os sectores/empresas, salva- 
guardando, naturalmente, o tipo de 
gestão específico de cada empresa. 


RÉSUMÉ Ce travail a comme objectif caracterizer 
la fonction personnel dans une concep- 
tion de gestion integrée et perspectiver 
tout ce qui concerne la relation 
gestion/information dans un dévélope- 
ment applicationnel capable de dépas- 
ser les traditionels problémes ou limita- 
tions des aplications de personnel fai- 
tes à mesure de chaque entreprise et 
des packages mêmes existents dans le 
marché portugais. Bien que le travail 
entourne le secteur bancaire, les con- 
ceptions presentées, par l'universalité 
de la fonction, s'appliquent à tous les 
secteurs/entreprises, sauvegardant, na- 
turellement, le type de gestion spécifi- 
que de chaque entreprise. 


1. APRESENTAÇÃO 


«A empresa não é apenas o local onde os ho- 
mens passam uma parte da sua vida diante de 
máquinas ou sentados a uma secretária. É tam- 
bém o ponto de encontro de influências huma- 
nas, sociais e económicas que se conjugam e se 
opõem, influindo nas decisões da entidade patro- 
nal e no comportamento dos empregados» 


A função de pessoal, independente do sector e da 
dimensão da empresa; apresenta particularidades 
específicas em relação às outras funções que a tor- 
nam complexa nos seus aspectos técnicos e incom- 


llídio Antunes 
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preendida nas suas relações inter-pessoais e institu- 
cionais. E uma função extremamente delicada, polé- 
mica e até contraditória, fundamentalmente porque 
os objectivos da empresa são quantificados, geral- 
mente, em termos economicistas e muito pouco em 
termos sociais e porque os gestores e técnicos de 
pessoal, na prática, estão subordinados à política 
imediatista do empresário português vocacionado to- 
talmente para o lucro financeiro a cada momento, 
isto é, em cada exercício ou seja ao fim de cada ano 
de actividade. Este imediatismo economicista e a 
subordinação dos gestores e técnicos não possibilita 
que a função pessoal seja a base integrada dos 
diferentes interesses sócio-profissionais no âmbito 
da empresa, antes pelo contrário: é o meio em que 
me cet o desencadear dos diferentes conflitos la- 
orais. 

Em termos informáticos podemos dizer que a fun- 
ção pessoal tende a ser grandemente informatizada, 
fundamentalmente nos aspectos administrativos, de 
cadastro, de planeamento, de absentismo e de análi- 
se estatística, embora a tendência ainda em vigor na 
maior parte das empresas portuguesas (grandes e 
médias) seja a de considerarem que a identificação 
do pessoal em ficheiros informáticos e o cálculo das 
remunerações (abonos e descontos) é só por si uma 
aplicação de pessoal. Esta situação, extremamente 
incorrecta e limitativa, é bem o exemplo do compor- 
tamento imediatista da maior parte dos nossos em- 
presários e da subordinação dos gestores e técnicos 
a essa política. Como não é esta a nossa opinião 
sobre uma aplicação de pessoal integrada nos as- 
pectos globais da função e nos objectivos da empre- 
sa, propomo-nos apresentar uma visão aplicacional 
mais ampla tendo como base os seguintes pressu- 
postos: 


— É na nossa opinião pessoal de conceitos de 
organização e gestão integrada que fundamen- 
tamos este trabalho; 

— Os princípios adoptados baseiam-se na reali- 
dade do sistema bancário que, em geral, apre- 
senta efectivos superiores a 4000 pessoas; 

— A metodologia de estudo e análise assenta na 
caracterização total da função e na apresenta- 
ção do desenvolvimento aplicacional de uma 
forma «macro» sem ir à definição de ficheiros, 
organizações, I/O, etc. porque a este nível de 
divulgação é-nos impossível, por diversos moti- 
vos apresentar a aplicação no seu todo meto- 
dológico, organizacional, informacional, progra- 
mático e explorativo; 

— As soluções propostas podem ser aplicadas 
(mesmo com pequenas nuances) a qualquer 
tipo de empresa fundamentalmente devido à 
universalidade da função pessoal e da informa- 
ção a produzir, embora existam sempre as 
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restrições/limitações próprias de cada tipo de 

—. equipamento informático; 

— O desenvolvimento deste trabalho não obedece 
a nenhuma metodologia de «caderno de encar- 
gos», manual de análise funcional ou orgânica. 
E sobretudo uma exposição sintética das gran- 
des questões que envolve uma aplicação de 
gestão de pessoal. 


2. CARACTERIZAÇÃO 


Quando um grupo de trabalho tem como missão 
estudar e analisar uma função e propor as soluções 
mais adequadas para uma melhor resposta e enqua- 
dramento dessa função dentro da estrutura orgânica 
e dos objectivos da empresa, a primeira condição a 
satisfazer, pelo próprio grupo, é caracterizar essa 
mesma função na sua globalidade histórica, técnica 
e estrutural. 

No que se refere à função de pessoal a caracteri- 
zação torna-se duplamente importante porque os re- 
cursos a estudar e gerir são humanos e a eficácia 
da empresa depende fundamentalmente da estabili- 
dade e motivação desses mesmos recursos. Sem 
pretendermos entrar no desenvolvimento da carac- 
terização (não porque nos falte material, mas funda- 
mentalmente porque o espaço e o veículo não são 
os mais aconselhados) não podemos deixar de apre- 
sentar os pontos essenciais, no que se refere à 
gestão de pessoal, que se distribuem por três gran- 
des áreas: 


A ER PUNÇAR DOS MÉTODOS DE GESTÃO 
DE PESSOAL 
O Despotismo 
O Paternalismo 
A Organização Científica da Empresa e o 
Factor Humano — o Taylorismo 
— Reconhecimento da importância do Factor 
Humano na Empresa 
A Tendência Humanitária 
Tendência Integrativa 
Tendência da Democracia Industrial 


2.2 POLÍTICAS E TÉCNICAS DE GESTÃO DE 
PESSOAL 


— Política de Remunerações 

— Política de Informação e Participação 

— Planeamento e Controlo 

— Recrutamento, Selecção e Acolhimento 

— Aprendizagem, Formação, Aperfeiçoa- 
mento e Reciclagem 

— Análise e Qualificação de Funções 

— Notação, Apreciação e Promoções 

— Transferências 

— Disciplina e Estabilidade 

— Condições de Trabalho 

— Medicina de Trabalho 

— Assistência Social 


DDD 
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Em relação a este último ponto, assistência e pre- 
vidência social, existe um grande número de ges- 
tores e técnicos de gestão de pessoal que consi- 
deram estas acções como uma das formas mais 
degradantes do paternalismo dentro das empresas 
porque estas acções devem ser desenvolvidas de 
uma forma global e no âmbito da competência do 
Estado. 
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A Estruturação da Função Pessoal 
Política Geral 

Os Objectivos Económicos e Sociais 
Missão e Tarefas da Direcção 
Programa de Acções 


3. DESENVOLVIMENTO APLICACIONAL 


Conforme o que atrás dissemos, a caracterização 
da função que se quer estudar e analisar é a primei- 
ra condição a satisfazer para um eficaz desenvolvi- 
mento aplicacional. Chamemos à caracterização da 
função a 1.º fase do estudo para o desenvolvimento 
aplicacional. 

A 2.º fase será dedicada à estrutura existente ou a 
implementar na Direcção. O organograma represen- 
tado na figura 1 expressa uma hipotética estrutura e 
hierarquização da Direcção de Pessoal. Em princípio 
as sub-funções da Direcção são (mais pormenor, 
menos pormenor) as que estão representadas no 
organograma, contudo a inserção na Direcção da 
sub-função VENCIMENTOS pode considerar-se 
polémica porque há quem defenda, com argumentos 
pertinentes, que ela pertence à Direcção de Pessoal 
e há outras pessoas que defendem, igualmente com 
argumentos válidos, que esta sub-função deve estar 
localizada na Direcção Financeira. Nós estamos no 
primeiro grupo fundamentalmente por razões de 
operacionalidade e de coordenação, razão porque a 
representamos no organograma. 
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FIG. 1 - ORGANOGRAMA DA DIRECÇÃO DE PESSOAL 
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A 3.º fase assenta no desenvolvimento funcional 
da função (passe a redundância) que, de acordo 
com o método top-down, está representado na figura 
2. Nesta figura é de salientar que qualquer entrada 
no diagrama acaba sempre com uma acção/output 
de controlo. Este controlo (embora pareça excessivo, 
na verdade não o é) tem uma importância extraordi- 
nária para garantir a qualidade das informações ar- 
mazenadas e para responsabilizar o utilizador pela 
sua gestão e manutenção. Através desta 3.º fase 
tem-se o «valor» da grandeza qualitativa e quantita- 
tiva da informação em presença e das suas inter- 
-relações na estrutura. 


— funções 

— remunerações 

localização (centro de custos) 
habilitações literárias e profissionais 
diversos 

pedidos de transferência 


Os lógicos do «histórico» representam: 


absentismo (ano a ano) 
funções desempenhadas 
promoções 

diversos 


CARREIRA 


PROFISSIO 


FIG. 2 - DIAGRAMA FUNCIONAL 


Na 4.º fase determina-se as relações lógicas entre 
a entidade «trabalhador» e as entidades lógicas 
no(s) ficheiro(s). O diagrama da figura 3 (cadastro) 
possibilita-nos a seguinte relação por cada entidade 
«trabalhador»: 


| lógico «nome/morada» 
n lógicos «filiação/agregado» 
| lógico «posição corrente» 
n lógico «histórico» 


Os lógicos da «posição corrente» (dados actuais) 
representam informações sobre: 


FILIAÇÃO/ 
AGREGADO 


FIG. 3 - DIAGRAMA CADASTRAL 


INFORMÁTICA 


NEL WEALIZAÇÕES 


Depois de termos estudado e analisado: 


a caracterização da função, 
a estrutura da Direcção, 

o desenvolvimento funcional, 
as relações lógicas, 


estamos em condições de estudar e estabelecer as 
relações inter-aplicaçõesa e inter-ficheiros. É a 5.º 
fase do desenvolvimento aplicacional. Esta fase é a 
essência da análise orgânica; é aqui que se deter- 
mina ou não os grandes parâmetros de eficácia da 
aplicação quer para o utilizador quer para o próprio 
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centro. O diagrama da figura 4 estabelece essas 
relações que, neste trabalho específico do sector 
bancário, se resumem a: 


— uma aplicação de pessoal que apresenta oito 
ficheiros (perfeitamente enquadráveis numa filo- 
sofia de base de dados); neste conjunto de 
ficheiros não estão representados o ficheiro de 
movimentos do mês e os ficheiros de trabalho; 
a aplicação fornece como sub-produtos as re- 
munerações fixas do mês e as regularizações 
eventuais do mês que funcionam como input da 
aplicação de vencimentos; o ficheiro de nomes/ 
moradas pode não existir se todos os trabalha- 
dores estiverem representados no ficheiro de 
1.º titulares da aplicação depósitos; 

— uma aplicação de vencimentos que tem como 
inputs principais os dados calculados a partir da 
aplicação de pessoal; esta aplicação, além dos 
mapas próprios de vencimentos, produz os mo- 
vimentos para lançamento em depósitos a or- 
dem dos valores líquidos a creditar a cada tra- 
balhador e os movimentos contabilísticos de 
acordo com o plano de contas da contabilidade; 
uma aplicação de depósitos e outra de conta- 
bilidade que mensalmente recebem movimentos 
a partir do cálculo de vencimentos. 


VENCI 


TOS 429 


As soluções para estes blocos dependem funda- 
mentalmente de: 


— necessidades do utilizador; | 
— disponibilidades de recursos informáticos; 
— custos/benefícios dos serviços a prestar. 


A partir do enquadramento destas três variáveis 
uma das hipóteses para o desenvolvimento orgânico 
da aplicação será: 


— totalmente Batch; 

— actualização dos ficheiros em Batch, produção 
de grandes outputs em Batch, pequenos 
outputs/«inquiries» on-line; 

— actualização dos ficheiros e «inquiries» on-line, 
grandes outputs em Batch; 

— totalmente on-line. 


Neste trabalho defendemos a segunda hipótese 
fundamentalmente baseada nas seguintes razões: 


— a periodicidade das actualizações devem ser 
mensais; 

— a periodicidade para produção de mapas de 
posição, de gestão e de estatísticas deve ser 
bem determinada; 


FIG, 4 - DIAGRAMA DAS NELAÇÕES INTER - FICHEIROS 


Em relação a este diagrama, específico para o 
sector bancário, podemos dizer que ele aplica-se a 
todo o tipo de empresas, para isso basta substituir 
os ficheiros representados na aplicação depósitos 
por banda magnéticas e/ou mapas pois serão estes 
suportes o input dos bancos para a respectiva movi- 
mentação da conta bancária de cada trabalhador. A 
6.: fase e última do desenvolvimento aplicacional 
caracteriza-se por definir e estabelecer os blocos de 
processamento. Sem grandes necessidades de apro- 
fundamento desde logo sentimos que existem dois 
grandes blocos: 


— actualização de ficheiros conforme figura 5; 
— produção de outputs conforme figuras '6 e 7. 
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— as necessidades do utilizador que podem ser 
enquadradas num processamento on-line basei- 
am-se sobretudo em pequenos «inquiries» indi- 
viduais. 


Nesta perspectiva há que justificar minimamente o 
diagrama da figura 5 que apresenta dois tipos de 
processamento: 


— simulado; 
— real. 


As vantagens desta solução baseiam-se funda- 
mentalmente em: 


INFORMÁTICA 


— possibilitar o controlo da informação que se 
quer actualizar; 

— possibilitar a correcção dos erros de codificação 
e de gravação; 

— responsabilizar o utilizador pela informação que 
a quando dá o OK para o processamento 
real; 

— uma única utilização dos ficheiros. 


É claro que existem desvantagens: 


— maior tempo de processamento caso não exista 
erros a corrigir (hipótese meramente teórica); 

— maior dificuldade para as Operações e Planea- 
mento pela existência de dois tipos de proces- 
samento. 


Pensamos contudo que estas desvantagens não 
têm o «peso» suficiente para contrariar as vantagens 
atrás descritas. 

Conforme atrás dissemos não especificamos os 
inputs/outputs da aplicação, embora eles estejam re- 
presentados na maior parte dos casos no diagrama 
funcional/figura 2, contudo não pretendemos terminar 
sem falar um pouco sobre o ficheiro «TABELAS» e 
os outputs principais. 


FIG. S - DIAGRAMA DA ACTUALIZAÇÃO DE FICHEIROS 


INFORMÁTICA 


gestão de pessoal 


A informação a armazenar numa aplicação de 
pessoal deve ser maioritariamente na forma de có- 
digo por duas grandes razões: 


— poupança de meméória; 
— facilidade de alterações. 


Assim defendemos a existência de um ficheiro de 
tabelas que expressem a estrutura e a relação entre 
códigos e dados. As principais tabelas e respectivos 
códigos a criar são: 


— Funções 

— Categorias Profissionais 

— Níveis de Remuneração 

— Subsídios Fixos 

— Centros de Custos 

— Habilitações Literárias e Profissionais 
— Absentismo 


Quanto aos mapas, ou grupo de mapas, Os princi- 
pais são: 


— POSIÇÃO: 
— Nomes e moradas 
— Habilitações literárias e profissionais 
— Antiguidade e funções 
— Sindicais 


— GESTÃO: 
— Quadros e Estruturas por Serviço e Geral 
— Transferências 
— Absentismo (Plano de férias, realizações, 
controlo) 
— Promoções (Plano, realizações, controlo) 
— Concursos 


— ESTATISTICAS (Histogramas e Distribuições): 
— Estrutura do Pessoal 
— Absentismo 
— Promoções 
— Rotação 
— Distribuição da massa salarial 


= 


ELABoLaçÃ 
Pedis0s 


FIG. 6 - DIAGRAMA DA PRODUÇÃO DE OUTPUTS 
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Por último devemos referir que a hipótese de pro- 
dução de micro-fichas do cadastro pessoal, de 
acordo com a figura 6, se justifica fundamentalmente 
na solução orgânica totalmente Batch, nas outras 
soluções a produção de micro-fichas não tem qual- 


quer razão de ser; assim como não se justifica a 
existência de pedidos formalizados em documentos 
numa solução que passe por qualquer coisa on-line, 
de acordo com a figura 7. 


FIG. 7 - DIAGRAMA DE PROCESSAMENTOS ON-LINE 


o computador apoia 
o seu dinamismo 


Disponha dos serviços de um grande 
equipamento pelo preço de um TERMINAL 


e TELEPROCESSAMENTO e 
e SERVICE BUREAU e 


— Concepção, análise e programação de sistemas 
— Processamento de dados 
— Recolha de dados 
— Block-time 
Temos ao seu dispor «PACKAGES» de Contabilidade Financeira e Analítica, 
e Racionamento de Stocks, Pacturação, Estatística, Custeio, etc. Vencimentos, Gestão 
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INICIAÇÃO ÀS BASES DE DADOS 


Objectivos: Apresentar os conceitos fundamentais 
associados à tecnologia das «Bases de 
Dados». Mostrar-se-ão as vantagens 
desta nova tecnologia em relação aos 
clássicos «ficheiros», bem como os cri- 
térios de escolha de «Sistemas de Ges- 
tão de Bases de Dados» 


Data: 7 a 11 de Fevereiro de 1983 
Horário: 14.30 às 17.30 h 
Local: Centro de Formação da Norma, em Lisboa 


INICIAÇÃO À INFORMÁTICA 


Objectivos: Apresentação dos conceitos fundamen- 
tais associados ao tratamento automático 
da informação, perspectivando a informá- 
tica como instrumento de apoio à gestão 


Data: 16 a 18 de Feverero de 1983 
Horário: 09.30-17.30 h 
Local: Centro de Formação da Norma, em Lisboa 
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Auditoria Informática 


RESUMO O crescente recurso à informática 
pelas organizações obriga a colocar 
o problema da Auditoria Informática 
a um nível superior ao simples trata- 
mento da contabilidade pelo compu- 
tador, sendo esse o objectivo deste 
trabalho. 


ABSTRACT The on going use of Informatics by 
organizations suggest we discuss 
the Audit problems in a higher lever 
than the simple accounting proces- 
sing. 


1. INTRODUÇÃO 


As ideias que se geram em redor da Auditoria 
Informática, são, em muita casos, pouco claras ou 
até bastante confusas e contraditórias, particular- 
mente no respeitante a campos tão importantes 
como: áreas, participantes, conhecimentos neces- 
sários, etc... 

Já vai longe o tempo onde se considerava a Audi- 
toria Informática apenas como uma auditoria de tra- 
tamento da contabilidade pelo computador, o que, 
não obstante ser, de facto, uma das facetas impor- 
tantes daquele tipo de trabalho, não corresponde de 
maneira alguma à visão que se deve ter sobre o 
problema. 

Assim, e porque se verifica que o crescente recur- 
so à informática não é, em muitos casos, acompa- 
nhado por medidas adequadas, pareceu oportuno 
abordar o problema da Auditoria Informática numa 
tentativa de, levantando ideias, não só definir o que 
se deve entender por aquela, como também chamar 
a atenção para a necessidade da sua utilização 
normal. 

Para atingir este objectivo dividiu-se o problema 
em duas partes complementares, onde na primeira 
(que corresponde ao presente artigo) se define o 
que se deve entender por Auditoria Informática e 
quais os seus principais tipos, e na segunda (que 
será apresentada num próximo artigo) se abordam 
problemas resultantes das definições anteriores, tais 
como: metodologias, formação e listas de controlo 
de Auditoria. 


2. DEFINIÇÃO 
Perante um problema tão complexo e por vezes 


tão pouco conhecido como é o da Auditoria Informá- 
tica, torna-se necessário que, em primeiro lugar, se 


Carvalhal Pires 
SOLINF 
dê uma noção concreta da problemática que envolve 


esta actividade para assim se tornar possível com- 
preendê-la, realizá-la e até mesmo a acompanhar de 


- Uma forma correcta. 


Considerando que um dos processos mais objecti- 
vos correntemente utilizados para identificar e estu- 
dar um problema, consiste na obtenção de respostas 
concretas a cada uma das 6 perguntas «clássicas» 
de análise, formuladas objectivamente em relação 
aos temas em estudo, apresenta-se nos parágrafos 
que se seguem numa definição genérica do que se 
deve entender como Auditoria Informática, através 
de respostas que, em relação a este assunto, as 
seguintes perguntas desencadeiam: 


— O que é? 

— Porque é necessária? 
— Quando é necessária? 
— Onde actua? 

— Como é desenvolvida? 
— Quem a executa? 


21— O que é? 


Analisando os objectivos, as funções e demais 
características da actividade de Auditoria Informática, 
verifica-se que a mesma é: 


— Um exame descontinuo efectuado ao longo do 
tempo a um Serviço e/ou a uma Solução Infor- 
mática, no sentido de garantir, aumentar ou me- 
lhorar, a segurança, a eficácia e a rentabilidade 
desse mesmo Serviço e/ou Solução. 


Como se verifica, esta definição contem uma deli- 
mitação muito vasta da zona de actuação deste tipo 
de trabalhos, ao contrário de que muitas vezes se 
pensa, quando se pretende associar Auditoria Infor- 
mática à actividade restrita do acompanhamento de 
um ou outro processamento que por hábito já era 
seguido por Auditores, antes de ser tratado automati- 
camente, como por exemplo no caso dos tratamen- 
tos contabilísticos. 


2.2 — Porque é necessária? 


O recurso cada vez mais generalizado ao trata- 
mento automático de dados para gestão associado à 
crescente tomada de consciência dos problemas que 
a utilização incorrecta de um computador pode tra- 
zer, tomada de consciência essa muitas vezes resul- 
tante da desmitificação que a Informática tem vindo 
a sofrer, leva a exigências cada vez maiores e mais 
conscientes de segurança, qualidade, prazos, cus- 
tos, etc... 
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Assim e concretizando, a necessidade real de Au- 
ditoria Informática é facilmente justificada através 
das seguintes respostas que, entre outras, se podem 
obter em relação à questão levantada neste ponto: 


— As Fraudes, os Erros, e as Anomalias não só 
podem acontecer nas mais diversas alturas, 
como podem não ser detectadas a tempo; 

— A facilidade de acesso à Informação nos siste- 
mas actuais tornou-se uma preocupação cons- 
tante pelos inumeros recursos que pode acar- 
retar; 

— Os conhecimentos e as soluções não podem 
pertencer a grupos restritos (técnicos ou não), 
pois caso contrário não só as chantagens po- 
dem contecer com relativa facilidade, como as 
interrupções acidentais de um fracasso podem 
comprometer significativamente a continuação 
do mesmo; 

— As Direcções e os Utilizadores em geral preten- 
dem perceber cada vez melhor e «mais claro» 
o que se passa na e com a Informática; 

— As soluções de tratamento automático de dados 
são, globalmente bastante caras; 

— Alguns fornecedores são muitas vezes pouco 
claros em relação ao que oferecem e por vezes 
omitem pontos importantes para induzir em erro 
interlocutores menos avisados. 


2.3 — Quando é necessária? 


Os problemas levantados no ponto anterior obri- 
gam a concluir que o acompanhamento da Auditoria 
Informática é necessário ao longo das diversas fases 
dos processos de desenvolvimento de tratamento 
automático de dados, desde o equacionamento das 
diversas soluções possíveis para o mesmo, até a 
execução corrente e normal dos trabalhos reais. 

Assim pode-se responder globalmente que a ne- 
cessidade da Auditoria se verifica em cada um dos 
seguintes quatro grandes grupos de situações: 


— Em estudos tendentes à implementação de 
soluções de automatização; 

— No desenvolvimento de sistemas e procedimen- 
tos para o tratamento da informação por via do 
computador; 

— Durante o tratamento da informação real atra- 
vés de processamentos informáticos; 

— Quando se verifiquem alterações ou outros tra- 
balhos de manutenção do sistema em funciona- 
mento. 


2.4 — Onde actua? 


Sendo a Auditoria Informática uma actividade que, 
tal como se tem vindo a verificar através das respos- 
tas aos pontos anteriores, pretende garantir uma cor- 
rrecta utilização dos meios de tratamento automático 
de dados realmente disponíveis, e sendo verdade 
que, para tal, se torne necessário um acompanha- 
mento do estudo dos problemas desde o início, con- 
clui-se que, a sua actuação deve incidir principal- 
mente nos seguintes pontos: 


— Nos estudos prévios e de oportunidade; 

— Na análise e demais fases do estudo dos sis- 
temas; 

— No arranque das soluções informáticas; 

— Nos trabalhos reais; 

— Nos processos de alteração a sistemas em fun- 

cionamento; 
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— Nos estudos de equipamentos e software; 
— No funcionamento dos serviços de Informática. 


2.5 — Como é desenvolvida? 


Para desenvolver o programa de Auditoria Infor- 
mática que os pontos anteriores definem, deve-se 
actuar através dos seguintes três tipos de acções 
complementares: 


— ESTUDAR 


e O funcionamento e as necessidades quer dos 
utilizadores quer dos Serviços de Informática; 

e A forma como as soluções informáticas são 
desenvolvidas e implementadas; 

e Os custos e tempos quer planeados quer 
verificados na realidade; 

e A rentabilidade dos processamentos face ao 
trabalho que realmente executam e outras 
formas de atingir resultados idênticos; 

e Os pontos críticos existentes e os que pos- 
sam aparecer com o desenvolvimento de no- 
vas formas de tratamento da informação; 

o e propostas de novas soluções; 

e etc... 


— TESTAR: 


e O cumprimento de normas e standards exis- 
tentes; 

e O funcionamento real das soluções imple- 
mentadas; 

e A finalidade, oportunidade e necessidade 
uer dos dados fornecidos quer dos resulta- 
os obtidos; 

e A satisfação dos utilizadores e dos informáti- 
cos em relação a trabalhos em desenvolvi- 
mento e processamento já em execução real; 

e etc... 


— RECOMENDAR: 


e Planos concretos de acção e alternativas a 
escolher; 

e Introdução de novas medidas ou normas de 
trabalho; 

e Alterações a procedimentos, estruturas, nor- 
mas standard, e outras; 

e etc... 4 


Conclui-se assim que o Auditor não deve limitar o 
desenvolvimento do seu trabalho ao estudo de situa- 
ções mais ou menos correctas, num determinado 
momento e ao longo do tempo, pois em comple- 
mento a essas acções, compete-lhe elaborar e pro- 
por medidas concretas tendentes a resolver proble- 
mas, melhorar situações ou prevenir o aparecimento 
de problemas. 


2.6 — Quem a executa? 


A resposta à pergunta de quem deve executar 
Auditoria Informática é complexa e por vezes um 
pouco polémica, motivo porque parece mais correcto 
responder a esta questão com a caracterização dos 
elementos a quem devem ser atribuídas estas fun- 
ções muitas vezes em equipa através de análise das 
perguntas postas: 


INFORMÁTICA 


INFORMÁTICA 


auditoria informática 


— Perfil pessoal 
— Situação ou enquadramento 
— Conhecimentos. 


— PERFIL: 


O perfil desejado para a Auditor Informático apró- 
xima-se bastante do geralmente requerido para um 
Analista Funcional (de organização informática), e 
caracteriza-se pela necessidade que aquele tem em 
possuir um elevado grau de: 


— lIdoneidade; 

— Maturidade; 

— Observação; 

— Abstracção; 

— Sintese; 

— Relacionamento. 


— SITUAÇÃO: 


Atendendo ao trabalho crítico (construtivo) que o 
Auditor de Informática necessita desenvolver, é ne- 
cessário que ele se encontre enquadrado na organi- 
zação e no trabalho de acordo com os seguintes 
pontos: 


e Com independência funcional e hierárquica em 
relação às chefias que se encontram relaciona- 
das, directa ou indirectamente, com os traba- 
lhos a acompanhar; 

e sem responsabilidades de qualquer ordem, nas 
actividades a controlar. 


— CONHECIMENTOS: 


Os Auditores de Informática têm de ter conheci- 
mentos profundos, sólidos e diversificados, nas se- 
guintes duas áreas distintas: 


e Informática, sem necessitar de ser a nível de 

pormenores da máquina, pela razão que terão 
de analizar, estudar e propor medidas que es- 
tão intimamente relacionadas e/ou dependentes 
da problemática dos processos de tratamento 
automático de dados; 
Procedimentos de Gestão, nos seus mais diver- 
sos ramos, porque irão estudar tratamentos ad- 
ministrativos dessas áreas, dependentes das 
características e leis do funcionamento que as 
mesmas têm. 


3. TIPOS DE AUDITORIA 


Se bem que possam existir diversas classificações 
para a Auditoria Informática é frequente considerá-la 
agrupada nos tipos que se apresentam de seguida, 
conforme se pretende uma análise da mesma 
quanto: 


— Ao âmbito onde se insere 

— Aos objectivos que se propõe atingir 

— Ao âmbito e objectivos (em conjunto). 
3.1 — Quanto ao âmbito 


De acordo com o campo de acção coberto pela 
Auditoria Informática, que pode ser mais limitado nos 


problemas a analizar ou mais generalizado, assim se 
consideram os seguintes grandes tipos: 


— OPERATIVA 


Quando se identifica com o estudo de uma ou 
várias funções inseridas num mesmo sistema 
ou problema concreto no sentido de detectar 
anomalias de vária ordem, existentes ou possí- 
veis e determinar suas causas, efeitos e solu- 
ções necessárias; 


— FUNCIONAL 


Caracterizada por uma análise objectiva e por 
vezes pontual de um problema global e geral- 
mente diversificado, recorrendo frequentemente 
a comparações com outros casos idênticos mas 
considerados correctos, no sentido de emitir jui- 
zos de valor e recomendações sobre os factos 
estudados. 


3.2 — Quanto aos objectivos 


Ao atender-se aos objectivos específicos que, em 
cada caso, se pretende atingir com uma acção de 
Auditoria Informática, esta pode ser classificada num 
dos seguintes grandes tipos: 


— DE VALORES 


Quando se visa o estudo de possíveis erros ou 
fraudes que afectam ou possam vir a afectar o 
conteúdo das informações, em qualquer ponto 
de um sistema; 


— DE PROCEDIMENTOS 


Tendente a garantir o cumprimento de normas 
e procedimentos establecidos ou, caso não 
existam, estudá-los e defini-los; 


— DE GESTÃO 


Quando se pretende avaliar a utilidade, a renta- 
bilidade e o avanço dos projectos informáticos, 
bem como o funcionamento e as estruturas de 
serviços, particularmente de Informática. 


3.3 — Quanto ao âmbito e objectivos 


As classificações apresentadas nos pontos anteri- 
ores referem-se a tipos simples de Auditoria Informá- 
tica porque, de cada vez, apenas se considera uma 
única temática de análise. 

Ao associar a classificação proposta quanto ao 
âmbito, com a apresentada quanto aos objectivos, é 
possível determinar a existência dos seguintes tipos 
compostos: 


— OPERATIVA DE VALORES 


Com este tipo de auditoria pretende-se unica- 
mente assegurar a existência e o correcto fun- 
cionamento de controles e demais procedimen- 
tos que: 


e Permitam detectar erros ou inverosimilhanças 
a nível de informações de entrada, tratamen- 


Vol. 4, N.º 2 


31 


. 
aah 


auditoria informática 


tos automáticos, informações de saída e cir- 
cuitos de informação, em toda a área do sis- 
tema informático em estudo; 

e Reduzam ao mínimo as possibilidades de 
fraudes, roubos e outras acções idênticas 
praticadas contra informaçõs, ficheiros, pro- 
gramas, tempo de máquina, utilização de re- 
cursos, eic... 


Como se verifica, o conjunto de acções sub- 
-entendidas neste ponto não se limitam a estudar O 
processamento correcto de informação no computa- 
dor, pois vai muito mais longe e pretende não só 
analisar o tratamento de dados antes e após o pro- 
cessamento automático, como também todo um con- 
junto de possíveis anomalias que, infelizmente, são 
mais frequente do que normalmente se pensa e 
apresentam custos muito elevados. 


— OPERATIVA DE PROCEDIMENTOS 


Neste tipo de Auditoria Informática estuda-se a 
existência, o cumprimento e o valor de todo um 
conjunto diversificado de normas de funciona- 
mento nos mais diversos domínios de um traba- 
lho ou projecto como por exemplo em relação 
a: 


e Desenvolvimento, arranque e manutenção de 
um sistema informático a nível do cumpri- 
mento de standards de análise programação, 
de metodologias de trabalho, de relação entre 
utilizadores e informáticos, etc. ... 

e Execução corrente e extraordinária de traba- 
lhos e processamentos concretos, quer a ní- 
vel de informática quer a nível de utilizadores, 
sobretudo tendo em vista os controlos, a se- 
gurança, a privacidade, o acesso, a divulga- 
ção e a oportunidade quer desses mesmos 
trabalhos quer da informação que se relacio- 
na com eles; 

e Manutenção e arquivos de documentação téc- 
nica e documentos de trabalho de um pro- 
jecto ou sistema; 

e Utilização de recursos de equipamento e pes- 
soal no contexto das definições existentes 
para os diversos trabalhos. 


Conclui-se pois que este tipo de Auditoria não 
centra a sua actuação no estudo do cumprimento de 
normas de trabalho dentro da Informática, na medida 
em que alarga a sua actividade para análise das 
actuações dos próprios utilizadores relacionados 
com os trabalhos concretos de Informática em es- 
tudo. 


— OPERATIVA DE GESTÃO 


Com este grupo de actividades de Auditoria 
Informática, pretende-se analisar a utilidade de 
uma determinada solução, bem como as suas 
relações custo/proveito, particularmente a nível 
de: 


e Qualidade, oportunidade e possível vantagem 
da informação a prestar ou prestada, em 
comparação com a existente previamente; 

e Utilização de controlos de gestão para o 
avanço de um projecto concreto ou execução 
de trabalhos reais bem identificados; 
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e Avaliação dos custos previstos para as diver- 
sas fases de estudo, arranque e execução 
real dos trabalhos da solução em análise, 
bem como comparação das mesmas com as 
realmente verificadas; 

e Ponderação entre os custos previstos e reais 
por um lado, e as vantagens adquiridas com 
a solução automática por outro; 

e Estudo da correcção e do realismo dos pla- 
nos de arranque da solução e execução real 
de trabalhos, e comparação dos mesmos com 
os tempos e datas que de facto aconteceram. 


Assim este tipo de trabalhos estuda o interesse e 
a garantia de gestão de um projecto informático, não 
apenas durante o desenvolvimento do mesmo, mas 
sim desde os estudos e planeamentos preliminares, 
até à execução real normal dos trabalhos ao longo 
do tempo. 


— FUNCIONAL DE PROCEDIMENTOS 


Este tipo de Auditoria Informática aborda o pro- 
blema das normas e demais standards de fun- 
cionamento das diversas funções genéricas de 
Informática, sem as ligar objectivamente a ne- 
nhum objecto ou sistema concreto, motivo por- 
que se pode dizer que com este ponto se pre- 
tende particularmente: 


e Estudar o funcionamento dos diversos depar- 
tamentos de Informática, no sentido de garan- 
tir a existência e o funcionamento de procedi- 
mentos standard tendentes a permitir uma 
boa rentabilidade e segurança de trabalho; 

e Definir e avaliar o cumprimento de normas e 
métodos de trabalho standard adequados às 
diversas funções necessárias (análise, pro- 
gramação, operação, etc...) bem como 
abrangendo todas as áreas de trabalho (me- 
todologias, documentação, relações, utiliza- 
ção de recursos, etc...); 

e Verificar a adaptação das instalações e dos 
equipamentos em geral bem como garantir a 
existência e correcto funcionamento de nor- 
mas de utilização e segurança física quer de 
umas quer de outras; 

e Avaliar definir e garantir a utilização global 
correcta do hardware e do software standard 
ou de base, bem como verificar a adequação 
dos mesmos nos serviços pretendidos. 


Desta forma, a Auditoria Funcional de Procedi- 
mentos estuda o problema do funcionamento stan- 
dard do sector da Informática, no sentido de, ao 
fornecer assim uma garantia de correcção e se- 
gurança, permitir trabalhos mais correctos, optimiza- 
dos e sem precalços de desenvolvimento. ou exe- 
cução. 


— FUNCIONAL DE GESTÃO 


Finalmente, este tipo de Auditoria preocupa-se 

com os grandes problemas de estruturas, inte- 

grações, pessoal, planos a longo praso e outros 

do mesmo tipo que se relacionam com a macro 

gestão da realidade Informática de uma em- 
resa. 

Abi as finalidades dos principais trabalhos 
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inseridos neste grupo podem ser resumidos nos 
seguintes pontos: 


Estudar a estrutura e o funcionamento global 
do Serviço de Informática, particularmente a 
nível de relações, hierarquias, substituições 
temporárias, responsabilidades, etc...; 
Estudar a inserção da informática na organi- 
zação global da empresa, bem como as liga- 
ções da mesma com os demais órgãos exis- 
tentes e a criar; 

Avaliar o Plano Informático existente ou dili- 
genciar no sentido da sua elaboração; 


auditoria informática 


Estudar critérios de avaliação e determinação 
do custo de projectos de estudo e execução 
de trabalhos reais; 

Avaliar o pessoal ligado aos trabalhos de in- 
formática no sentido da optimização e se- 
gurança destes últimos; 

Estudar as relações globais entre utilizadores 
e informáticos; 

Concluir sobre as opiniões que os utilizadores 
têm em relação aos serviços que a informá- 
tica lhes presta; 

Avaliar a rentabilidade global da informática 
no contexto alargado da empresa que serve. 
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RESUMO  Efectua-se uma síntese e crítica da 
forma como têm sido conduzidas a 
reflexão e a discussão sobre a «For- 
mação em Informática» em Portugal. 
Defende-se uma metodologia a ser 
usada para realizar ou prosseguir es- 
sa discussão e faz-se uma indicação 
(não exaustiva) de documentos de 
trabalho que lhe podem servir de su- 
porte. 


ABSTRACT We do a synthesis and criticism of 
the reflexion and discussion on 
«Education in Information Proces- 
sing» carried out in Portugal. 

We defend a methodology to support 
further discussion, and finally we re- 
fer the main papers on this topic. 


O problema da formação em informática em Portu- 
gal tem sido muito referido, mas pouco e mal discu- 
tido. A afirmação pode parecer paradoxal, mas é 
verdadeira. 

A importância do tema mete-se pelos olhos dentro. 
Que existem carências também se sabe. Mas o ata- 
que sistemático e rigoroso das causas e medidas a 
tomar, ou até a sua análise ampla no seio da comu- 
nidade informática (e não só) tem escasseado. E as 
discussões ou contribuições não vão (e em muitos 
casos, dada a forma como são lançadas, não podem 
sequer ir) até aos fundamentos. 

Com este artigo, que me foi solicitado, não viso 
tanto dar mais uma opinião sobre o que se deve 
fazer em matéria de formação informática em Portu- 
gal. Pretendo antes tentar analisar as diferentes dis- 
cussões ou contributos que têm surgido e traçar 
algumas bases para que uma discussão futura se 
possa processar com um mínimo de hipóteses de 
eficácia. Sem se definirem tais bases continuaremos 
daqui por 10 anos a lamentar-nos do que se não fez 
nem discutiu. 


1. BALANÇO DAS DISCUSSÕES ANTERIORES 


Que me lembre o problema foi lançado à comuni- 
dade informática de forma não sistemática no 1.º 
CPI. E foi efectivamente discutido de forma alargado 
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A formação em Informática. 
Um ponto de vista pessoal 
para recolocar a discussão 


A. F. Silva * 


em duas ocasiões com metodologias e condições 
diferentes: no 2.º ENI e no 2.º CPI. No intervalo 
houve algumas contribuições individuais. 


11 O 2.º ENI 


Antes e durante o 2.º ENCONTRO NACIONAL DE 
INFORMÁTICA, a API convidou os informáticos a 
analisarem de forma detalhada e prolongada o pro- 
blema, primeiro no âmbito dos trabalhos prepara- 
tórios, depois durante um curto meio dia no próprio 
Encontro. 

Como se sabe a participação nos trabalhos pre- 
paratórios foi extremamente diminuta, pelo que o 
texto proposto acabou por ser redigido por cinco 
pessoas (todas aliás ligadas à informática chamada 


de gestão). . 
"Quanto à discussão no Encontro, ela foi, como 
tinha de ser, extremamente superficial — muita 


gente para pouco tempo. O texto final aprovado (se 
se pode falar de «aprovação») tem apesar disso 
alguns méritos que convém destacar: 


a) Explícita que o 2.º ENI «não pode aprovar te- 
ses ou resoluções definitivas» mas antes «ini- 
ciar uma abordagem e discussão do proble- 
ma», «a qual deve ser em seguida continuada 
e aprofundada, quer entre os informáticos, quer 
na sociedade em geral». 
Isto é, o Encontro que reunia os informáticos 
portugueses, que tinha dado condições a todos 
para participarem durante seis meses nos tra- 
balhos preparatórios e nas decisões do Porto, 
não se sentiu capaz de enviar «cartas abertas 
ao Governo», sugerir cursos ou conteúdos, 
mandar bocas ou exercer pressões. Um com- 
portamento raro como se sabe. 
Ao recomendar à AP| que «crie um grupo de 
trabalho especializado» e que «promova am- 
plos debates, colóquios, etc.». 
Ao referenciar as fontes actuais de formação 
em informática — empresas de serviços, em- 
presas construtoras, organizações que utilizam 
a informática e ensino oficial — e clarificar as 
áreas profissionais a que é preciso dar forma- 
ção: informáticos, utilizadores não informáti- 
cos(!) e professores de informática(!!), faltando 
aqui talvez clarificar apenas a importância da 
formação a dar às chefias dentro da informática 
e acima dela. E 
d) Ao estabelecer recomendações razoáveis rela- 
tivamente às medidas das futuras. 


b 


— 


(0) 


ir 


Não cabe aqui repetir o que então se aprovou e o 
leitor pode encontrar no Volume 2, n.º 2 (Abril/Junho 
de 1981) da Revista de Informática. Sobre o con- 
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a formação em informática 


texto e lacunas da formação na informática chamada 
de gestão a análise aí efectuada pode ainda ser 
quase completamente subscrita. 

Cabe no entanto aqui fazer uma observação: com 
excepção dos «pareceres» ou contributos individuais 
adiante referidos, a maioria das discussões que se 
travaram depois do Encontro fizeram quase comple- 
ta tábua rasa destas conclusões e processaram-se 
como se elas nunca tivessem sido produzidas. 

Num aspecto isso é aliás gritante: nessas discus- 
sões, quando se fala em «formação em informática», 
tem-se sempre implícita a formação dos informáticos 
(em particular dos «técnicos de informática» e rara- 
mente dos utilizadores, por um lado; e por outro, 
está-se sempre a pensar na formação dada no en- 
sino oficial (e não a que é dada pelo conjunto das 
instâncias que a alínea c) aponta). 

Ora ao fazer-se isso, está-se já a discutir apenas 
uma pequena porção do problema — e de forma 
alguma a mais importante. 


1.2 O intervalo entre o 2.º ENI e o 2.º CPI 


No período posterior ao 2.º ENI seria de esperar 
que ao menos a API respeitasse as duas recomen- 
dações que lhe foram explicitamente feitas (alínea 
b). Não o fez! 

E quase parece que se pretendeu manter as ditas 
conclusões na gaveta o tempo suficiente para elas 
irem sendo esquecidas e o problema poder ser re- 
colocado como certas pessoas gostam de o colocar 
— falando só de ensino oficial, em particular univer- 
sitário, e falando apenas da formação dos «informá- 
ticos». 

No intervalo entre o 2.º ENI e o 2.º CPI houve 
apenas (que me lembre) dois contributos significa- 
tivos. 


a) O primeiro era constituído por pareceres de 

pessoas (que não tinham estado no Encontro 
nem na sua preparação!) publicados no mesmo 
número da revista em que se publicaram as 
conclusões. 
Pareceres equilibrados de que um merece par- 
ticular realce, por criticar «o carácter opinioso 
do texto» (como se fosse condenável ter opi- 
niões — ou será mesmo «oficioso» como 
aparece escrito?) e lamentava que sobre a Uni- 
versidade ele fosse «demasiado esquemático» 
(dando aliás abertura para nada esquemáticos 
e nada maçadores textos e comunicações so- 
bre esse assunto). 

A meu ver este parecer é curioso pois ele 
diz, embora discretamente, o que muita gente 
pensou mas não teve a coragem (ou o des- 
caramento) de dizer. E foi por isso (ou assim o 
julgo) que tais conclusões foram silenciadas (se 
me é permitido dar uma opinião...). 

Uma carta aberta ao Governo foi a 2.º contri- 
buição. Que o Governo, está-se mesmo a ver, 
é a instância mais adequada para (saber) re- 
solver este (e outros) problemas. 

Não cabe aqui analisar tal carta aberta. Apenas 
salientar que embora refira as conclusões do 
2.º ENI é apenas para as aproveitar num as- 
pecto marginal pois o que nela se trata é, mais 
uma vez, O ensino oficial. 

Ora como o 2.º ENI lembrava, os sistemas in- 
formáticos desenvolvidos em Portugal foram 
desenvolvidos por pessoas que não tinham 
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passado por formação universitária em informá- 
tica (embora tivessem em geral passado por 
formação universitária noutras áreas). Foi isso 
mau? Ou foi isso bom? Esta questão nunca foi 
discutida. E há razões de peso para a silenciar 
sistematicamente. 

(EPI 

Chegou-se assim ao 2.º CPI. Não é aqui oca- 
sião para analisar este acontecimento no seu 
conjunto (embora o aumento substancial do 
preço de inscrição, tornando obrigatório o jantar 
— de luxo —, convidasse já, por um lado à 
«passagem de modelos» e, por outro, à inscri- 
ção priveligiada de membros de organizações 
enquanto tais — com as consequências que 
facilmente se calculam), mas apenas no que se 
refere ao problema da formação. 

Neste domínio se exceptuarmos uma ou 
duas teses, uma de interesse muito discutível, 
a outra mais interessante (ao falar especifica- 
mente sobre «formação de utilizadores»), e dis- 
cussões avulsas de corredor, a análise (?) do 
problema da formação circunscreveu-se a um 
«painel» formado por «oradores oficiais», esco- 
lhidos não se sabe com que critério, (se me 
recordo não estava presente na mesa nenhum 
dos relatores do 2.º ENI, o que não deixa de 
ser curioso!), instalados num palco-púlpito, de- 
tentores da razão, com direito a responder no 
fim, para repor «a legítima verdade», e um 
público de miudos contestatários mas discipli- 
nados (que aliás se portaram como deles se 
esperava e foram admoestados . mansamente 
como convinha). Inútil. 

Quanto à criação de tal grupo de trabalho, às 
discussões abertas e amplas (colóquios, mesas 
redondas, de facto redondas..., paineis nunca!) 
ainda continuamos à espera. E da sua falta nos 
lamentaremos talvez ainda durante e depois do 
3.º ENI (ou do 3.º CPI?). 


2. AS BASES DA DISCUSSÃO A HAVER 


Não é aqui ocasião, como se calcula, para forne- 
cer um contributo pessoal sobre «o que se deve 
fazer em formação informática neste país». 

Cada pessoa parece estar convencida de ser de- 
tentora de toda a verdade e saber tudo sobre o que 
se deve fazer, o que seria melhor fazer, e insiste em 
no-lo dar a conhecer em cartas abertas, em artigos 
de jornal, etc.. Mais não! 

Em vez de dar mais uma opinião «definitiva e 
fundamental» sobre o problema, prefiro dar a minha 
opinião sobre «as bases da discussão», isto é, clari- 
ficar de um ponto de vista necessariamente pessoal 
e subjectivo, quais devem ser as metodologias e 
critérios para proceder a uma ampla discussão do 
problema no seio da comunidade informática e da 
sociedade em geral. Discussão no fim da qual (e 
não antes!) se tirem as conclusões! 

Essas bases são a meu ver as seguintes: 


(1) A discussão do problema da formação em 

informática tem de partir da base de trabalho 
constituída pelas conclusões do 2.º ENI, no 
sentido de alargar a discussão e desenvolver 
e aprofundar as conclusões. 
Tal discussão tem de ter em conta as várias 
fontes de formação que efectivamente exis- 
tem (e permitiram a informática em Portugal) 
e não apenas uma. 
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(3) Tem de se analisar como primeira prioridade 
o problema da formação dos utilizadores não 
informáticos da informática (directos e in- 
directos, incluindo gestores aos diferentes ní- 
veis) e dos diferentes níveis de chefia na (e 
acima da) informática e não apenas, nem 
principalmente, a formação dos chamados in- 
formáticos (analistas, programadores, etc.). 
Tal discussão tem de se debruçar não ape- 
nas sobre a formação em informática mas 
sobre o quadro global da formação no mundo 
actual — percebendo de uma vez por todas o 
impacto da mudança tecnológica (e informá- 
tica!) no mundo actual, em vez de se conten- 
tar em coçar o umbigo da dita (informática)... 
(5) Isso passa por uma análise do ritmo de vida 
e de obsolescência crescente dos conheci- 
mentos adquiridos em qualquer profissão (e 
em particular em informática) e da definição 
das melhores formas de «educar para a mu- 
dança» e «educar durante toda a vida». Isso 
coloca os problemas da auto-aprendizagem e 
da formação permanente (e não apenas da 
reciclagem — aliás confundida frequente- 
mente com «cursos de reciclagem», mestra- 
dos, etc.) como os problemas centrais a re- 
solver. 

Essa análise obriga a um entendimento da 
ciência e da tecnologia, não como um pro- 
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(aliás ultrapassado do ponto de vista episte- 
mológico), mas assentando numa concepção 
da evolução científica como passando perio- 
dicamente por profundas «revoluções científi- 
cas», cujo ritmo aliás é exponencialmente 
acelerado — sendo precisamente isso que 
obriga a que toda a formação seja hoje uma 
preparação para a mudança contínua. 
Partindo desta perspectiva, importa analisar, 
sem preconceitos se a Universidade ainda é 
a forma mais adequada de formação (em 
informática e não só), ou se doravante o es- 
sencial da formação se fará fora da escola... 
como em informática se vem fazendo há mui- 
to tempo em Portugal. 

Toda esta análise passa por retomar as fon- 
tes onde estas discussões se vêm proces- 
sando, e o material bibliográfico dos países 
onde se faz e estuda a informática, em vez 
de se continuarem a receber as receitas em 
2º ou 3.º mão e já «reelaboradas» pela (li- 
vresca) cultura francesa (da qual aliás já só 
nós e alguns outros — poucos — países do 
3.º mundo ainda somos, neste domínio, tribu- 
tários). 

Para coordenar todo este processo de dis- 
cussão a API deve nomear a Comissão Pre- 
vista nas Conclusões do 2.º ENI. 
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(10) Essa comissão deve: 


— elaborar um conjunto de temas de dis- 


cussão 
— recolher bibliografia sobre esses temas e 
divulgá-la 
— promover várias discussões com te- 
mários, público e âmbito diversificados e 
ir divulgando os resultados parciais 
— preparar um relatório a aprovar com 
carácter de recomendação num próximo 
ENI (se tudo correr bem, no 4.º). 
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cesso de evolução gradual e continuista 


3. ALGUNS DOCUMENTOS DE TRABALHO 


Os pontos anteriores, de formas diversas, têm sido 
analisados em várias ocasiões. Sobre alguns deles 
há documento de base que é indispensável ler antes 
(e não depois) de se iniciar a discussão do pro- 
blema. 

Passo a indicar alguns dos documentos que os 
pontos de discussão anteriormente mencionados me 
sugerem, certo de que outros documentos, tão ou 
mais importantes, serão aduzidos por outras pes- 
soas. 

Sobre as alíneas 1, 2, 3 (do ponto Il): as conclu- 
sões do subtema Formação do 2.º ENI (já leu?). 

Sobre a alínea 3: O texto de James Martin, «Appli- 
cation Development Without Programmer's». 

Sobre as alíneas 4 e 5: o Capítulo 23 (The 
Change Needed in Education) do livro de James 
Martin, «Computerized Society» 

Sobre a alínea 6: a obra de T. S. Kuhn, «The 
Scientific Revolutions» (University of Chicago Press, 

962). 


Sobre as alíneas 5 e 7: todos os trabalhos de Eric 
Reimer, Paul Goodman e lvan lllich, o relatório Fau- 
re («Aprender a Ser», Livraria Bertrand, 1977) e as 
matérias seleccionadas pela Comissão Faure («A 
Sd do Futuro», Unesco, Livraria Bertrand, 

78). 


4. UMA REFERÊNCIA FINAL 


Dos documentos referidos um é de 1962 (o de 
Khun), outros são de 71 (um livro de James Martin e 
vários textos da Comissão Faure). Não será isto 
ultrapassado? Já estamos em 1982! 

Nas questões da epistemologia e da formação/ 
educação o que me parece faltar às discussões a 
que tenho assistido é... formação de base. Essa não 
tem data. 

Mas não apenas. Mesmo sobre informática as dis- 
cussões que travamos em 1982 são muito mais limi- 
tadas, muito mais «de vistas curtas», muito mais 
obsoletas das de certos autores em... 1971. 

Considere-se o capítulo 23 do livro de James Mar- 
tin já referido. 

Olhe-se a citação com que começa o capítulo: 


«Today's television child is bewildered when 
he enters the nineteenth century environment 
that characterizes the educational establish- 
ment>. 


- 


Observações: 


— Não estaria ele, em 1971, mais avançado do 
que nós? 

— Não andaremos nós a tentar reformar as insti- 
tuições do século XIX, sem nos perguntarmos, 
em relação a cada uma delas, se não será 
mais fácil deitá-las para o caixote do lixo (aliás 
como se faz a certas aplicações informáticas 
quando já não servem, embora nessa área 
como nesta haja sempre «interessados» em 
que isso não aconteça). é 
(5 minutos de pausa para Oo leitor pensar em 
todas as instituições do séc. XIX — e 

anteriores — que deitaria fora... se pudesse). 
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a formação em informática 


Olhe-se agora os subtítulos dentro do capítulo re- Isto é de 1971. Não andaremos nós, em 1982, a 
ferido: discutir apenas uma pequeníssima fracção do pro- 
- blema (e nem sequer a mais importante)? Problema 
— Education for Leisure (!) esse que, aliás, já é hoje mais amplo e mais comple- 
Change Needed in Teachers (!!!) xo que era então — mas no sentido que esse texto 
Elementary Schools (2 páginas) já abria e não sem sentido contrário. 
Secondary School (1/2 página) 
Universities 
Education Out of School 
Half-Life of Training * Este ponto de vista é pessoal e responsabiliza apenas o seu signatário. 
Lifel L : Nenhuma pessoa, entidade ou organização, com ele directa ou indirecta- 
Ie ong- earming mente relacionada, pode ser considerada como concordando com os pon- 
Machine Couseling tos de vista aqui defendidos. 


WORKING CONFERENCE 
on System Description Methodologies 
(CT-2) 


23 a 27 de Maio, 1983 


Keskemet, Hungria 


ETATRONICA — O SEU AMIGO NA TRANSMISSAO DE DADOS 
A MAIS COMPLETA GAMA DE EQUIPAMENTOS DE DIAGNÓSTICO, MEDIDA, 
ANÁLISE, CONTROL E TRANSMISSÃO PARA TELEPROCESSAMENTO 

EQUIPAMENTOS DE TESTE: 


— DIGITAL E ANALÓGICO EQUIPAMENTO DE COMUTAÇÃO E PATCH: 
e — DIGITAL, ANALÓGICO E COAXIAL. 


LDE E] TATA BLIS 
ç es 
z 


E, 
1 


UMA GAMA COMPLETA DE MODEMS: 
— EM BANDA DE BASE E DE CANAL 
— TELEGRÁFICOS. 


Rua Cidade de Bolama, 3 r/c Dt.” e 1800 LISBOA 
TELFS. 319980 / 319919 e TELEX 18519 
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NTOINIDIOMBIA PERNA 


Em todas as fases de desenvolvimento 
do seu sistema de informações 
«« da concepção à instalação, na utilização e diálogo... 
você beneficia das maiores vantagens 
estando com a Cassel Data — Data General 


A COMPANHIA DE COMPUTADORES 
EM QUE OS SISTEMAS FAZEM A DIFERENÇA 


O ad 


mM 


SORUBAL SOR 


SISTEMAS COMPUTADORES ELEC 


AS MELHORES MARCAS | 


AINDA MELHOR QUE O APPLE Il = 


vom 


Microcomputador compacto transportável, com o microprocessador 6502 (Z80 e 6809 opcionais), 

totalmente compatível com o Apple Il permitindo a utilização, sem quaisquer modificações, de 

todos os periféricos, acessórios e programas do Apple Il (All). 

— Teclado profissional alfanumérico e numérico com 72 teclas, incluindo 7 de funções, seleccio- 
nável QWERTY/AZERTY (no All o teclado numérico é opcional). 

— Memória central «standard» de 96 K RAM (contra 48 K RAM apenas do All). 

— 14 «slots» para gps (contra 8 apenas do All). 

— Módulo de cor PAL e modulador RF incorporados (opcionais no All). 

— Som em altifalante próprio e através de qualquer televisor. 

— Fonte de alimentação tipo industrial de 5 Ampéres. 

— Ventilação natural ou forçada (opcional). 

— EPROM como gerador de caracteres c/conjunto de 255 caracteres reprogramáveis, ex.º maiús- 
culas e minúsculas, pseudográficos, grego, caracteres portugueses, etc. 

— Vídeo de 24 linhas x 40 colunas (80 colunas opcionais), com saídas para monitor e televisor a 
cores ou a preto e branco, 

— Linguagem de programação disponíveis: BASIC (Applesoft, integer e Microsoft), UCSD Pascal, 
Fortran 77, Cis Cobol, Pilot, Logo, Forth e Assembler 6502, etc., etc.. 


e CONCEDEMOS AGÊNCIAS EM DISTRITOS AINDA DISPONÍVEIS e 


Aproveite as condições especiais da nossa campanha de 10.º aniversário 


Solicite hoje mesmo informações pormenorizadas e assista a uma demonstração 
(marcações pelo telefone 89 65 55) 


Apple Il + PEARCOM (Apple Il compatível) + Apple + COLUMBIA (IBM 
compatível) + CORVUS Concept (32 bits) + CENTRONICS (impressoras) + CORVUS (discos 
rígidos) + KAGA/TAXAN (monitores de vídeo) 


SORUBAL, s.a.r.l. 


Rua Gen. Pimenta de Castro, 15-8º 1700 Lisboa «HARDWARE» E ASSISTENCIA TECNICA E «SOFTWARE» 
Rua Teixeira de Pascoais, 1-B 1700 Lisboa á 
Telefs. 80 64 63/80 51 65 Telex 12775 SORBAL P 
Abertos da 09.00 às 19.30 h ininterruptamente de 2.º a 
6.º-feira (excepto feriados) 


Vol. 4, N.º 2 INFORMÁTICA 


JUBAL SORUBAL 


TRÓNICA | TELECOMUNICAÇÕES 


AOS MELHORES PREÇOS 


TUDO O QUE O IBM FAZ... E MAIS 


COLUMBIA 


PS A MAIS DE 1200 LP.M. 


THE CORVUS CONCEPT 
DISCO RÍGIDO CORVUS 


É um 16 bits. Compatível em «hardware» e «software» com o microcomputador IBM, o que 
quer dizer que utiliza todo e qualquer AS já desenvolvido para o IBM. E as suas 
características excedem mesmo as do IBM. 

Sistemas operativos de 16 bits CP/M-86 e MS-DOS REM PC DOS ou 86-DOS), MP/M-86, 
OASIS-16 e XENIX. Microprocessador 8088, memória de 128 K RAM expandível até 1 mega- 
byte, 2 interfaces série RS 232 e 1 interface paralelo Centronics, 2 unidades de diskette de 1 
megabyte ou 1 unidade de diskette de 0,5 megabyte e 1 disco rígido de 10 megabytes, 8 
«slots» de expansão, etc. Teclado separado para comodidade. Capacidade de multiproces- 
samento, sendo possível dispor até 64 postos de trabalho simultâneos com as unidades de 
disco rígido CORVUS e o n/dispositivo CORVUS Omninet e beneficiando de 20 a 80 
megabytes em linha! E tudo por um custo certamente muito inferior ao que imagina. 


O NOSSO PREÇO DEIXA OS 
OUTROS LÍVIDOS... 


A2S1048P Microcomputador Apple Il Europlus 48K RAM 


Preço corrente: Esc. 197 830$00 
NOSSO PREÇO: Esc. 119 900$00 


NOVAS INSTALAÇÕES (1.º tase) | A PARTIR DE JANEIRO/83 


Na encosta das Olaias (ao Areeiro) 
RUA AQUILES MACHADO, LOTES 10 11 E 12 — 1900 LISBOA 
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ORGANIZAÇÃO E GESTÃO/MARKETING/INFORMÁTICA/FORMAÇÃO 
nado do Sd ai ca 


Centro de Formação da NORMA 
Av. Fontes Pereira de Melo, 31 r/c - 1000 LISBOA - Telefs. 545183 - 545220 - 545368 


Delegação no Porto 
Rua de Faria Guimarães, 383-1º - 4000 PORTO - Telefs. 402161 - 402909 


A moderna metodolog 
turada de programas. 
Tendo sido desenvolvida no início da década de 70 foi implantada com êxito em instalações dos 
EUA e da Europa Ocidental, nomeadamente na Inglaterra, Países Nórdicos e Alemanha Federal. 


METODOLOGIA DE DESENHO ESTRUTURADO DE PROGRAMAS DE MICHAEL JACKSON 


Módulo | — 28 de Fevereiro a 4 de Março de 1983 
Módulo Il — 14 a 18 de Março de 1983 

Horário: 09.30 às 17.30 h 

O seminário será coordenado por Paulo Azevedo (BPSM) 


ia de Michael Jackson é considerada das mais fiáveis na concepção estru- 


Apresentar-se-á a metodologia de Jackson e levar-se-ão os participantes à concepção de programas cuja estrutura 
reflicta exactamente as especificações dos problemas a resolver, mesmo para sistemas com grande complexidade. 
Desenvolver-se-á uma nova, unificada e eficaz perspectiva de concepção de programas e sistemas. 


Industrial Robotics 


Discrete Manufacturing 


Rua Coelho da Rocha, 66-r/c-esq. - Telefone 674838 - 1300 
LISBOA 
(CAMPO DE OURIQUE) 


PROCESSAMENTOS 


CONTABILIDADE x SALÁRIOS x FACTURAÇÃO 


RECOLHA DADOS 


CARTÃO e BANDA e DISKETTS e CASSETTS 


CURSOS INFORMÁTICA 


RECOLHA DADOS PROGRAMAÇÃO 
IBM 3742.IBM 5280 PL1 COBOL RGIl BASIC PASCAL 


Working Conference 
6 a 8 de Junho 1984 


Como, Itália 


COMPUTADORES 


COMPUCORP 
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1. CONSIDERAÇÕES PRÉVIAS 


Sem dúvida que a solução informática se torna 
cada vez mais indispensável à vida das empresas. 
No entanto, a informática deve ser considerada 
como um meio de automatizar funções para a pros- 
secução dos objectivos da empresa e não como um 
fim em si. Esta afirmação, aparentemente trivial, é 
contudo, contrariada quotidianamente continuando a 
assistir-se à aquisição de equipamentos informáticos 
para, como por milagre, resolver todos os problemas 
com que se debatem as organizações. 

É preciso frisar que, para uma empresa que se 
decida pela automatização a melhor solução passa 
quase sempre, pela utilização prévia dos serviços 
duma empresa fornecedora de software. A decisão 
de alugar ou comprar um computador só deve ser 
tomada, em nosso entender, após a obtenção de 
alguma sensibilização sobre o impacto da informá- 
tica na estrutura empresarial. A experiência demons- 
tra que após o abandono dos métodos manuais, não 
mais é possível voltar para trás... 

A selecção de equipamentos é, por sua vez, uma 
tarefa bastante complexa. Os elementos apresenta- 
dos em seguida dão uma ideia das características 
mais gerais, de várias marcas comercializadas entre 
nós. Mas, é desejável não esquecer outras questões 
de importância capital, de entre as quais destacamos 
as seguintes: 


— À maior parte dos equipamentos requerem con- 
dições de instalação adequadas (temperatura, 
ventilação, humidade, etc.), no entanto, é for- 
çoso reconhecer que também devem ser asse- 
guradas condições de trabalho adequadas às 
pessoas que com eles vão trabalhar. Verifica- 
mos que muitas vezes este aspecto é ignorado. 
O investimento nas condições ambientais re- 
vela-se profícuo a prazo. 

— Em caso de avaria devem estar salvaguardadas 
as condições de manutenção que permitam re- 
pará-la em tempo útil. E fundamental garantir a 
existência, em local acessível duma configura- 
ção idêntica à adquirida onde, no caso de pro- 
blemas inultrapassáveis, seja possível desen- 
volver os trabalhos correntes. Mesmo que não 
ocorram avarias é conveniente que, periodica- 
mente, esta solução de emergência (back up) 
seja testada. Se existirem modelos já instala- 
dos, é sempre proveitosa uma troca de impres- 
sões com os clientes da marca a adquirir, no- 
meadamente sobre o tipo de resposta a situa- 
ções de avarias. 

— À configuração a adquirir deve responder às 
solicitações imediatas e dos curto/médio prazos 
de tratamento da informação, implicando um 


inquérito equipamentos 


Panorama dos equipamentos 
de médio e grande porte, 
comercializados em Portugal 


Jorge Barata 
LNEC 


estudo prévio dos volumes de informação e do 
seu crescimento. 

— Devem ser salvaguardadas as possibilidades de 
expansão nomeadamente dentro de cada mo- 
delo. É importante prever os custos dessa ex- 
pansão inserindo-os na previsão de despesas 
do curto e médio prazos. 

— A formação proporcionada pelos fornecedores 
deve ser condição suficiente para a operação e 
para a utilização eficiente dos recursos da má- 
quina. Contudo é bom não negligenciar outras 
fontes de formação. 


Pensamos que estas questões devem ser equa- 
cionadas antes da opção de aluguer, ou compra, 
aproveitando a margem de manobra ainda existente. 
Evidentemente que depois existem todas as ques- 
tões técnicas que devem ser exaustivamente testa- 
das e comparadas recorrendo-se, eventualmente, ao 
benchmark. A listagem dessas questões fica, no en- 
tanto, fora do âmbito deste artigo. 

O nosso objectivo é apenas realçar o facto de que 
a decisão de alugar ou comprar um equipamento, 
deve ser bem ponderada e enquadrada nos planos 
da empresa, sob pena de puder comprometer o seu 
futuro. Aliás, na ausência de pessoal para o desem- 
penho dessa tarefa, é aconselhável o recurso a um 
bom consultor de informática. 


2. APRESENTAÇÃO DOS RESULTADOS DO IN- 
QUÉRITO 


O inquérito agora apresentado pretendeu fazer o 
levantamento de algumas das principais característi- 
cas de duas gamas de sistemas considerados de 
médio e grande porte, da formação proporcionada 
pelos fornecedores e, finalmente, dos custos aproxi- 
mados de duas configurações standard, para cada 
um dos fornecedores. Para o efeito, foram concedi- 
das duas grelhas. A primeira das quais foi utilizada 
para as características sumárias do hardware e soft- 
ware (quadros IV e V) formação ministrada (quadro 
Vi) e datas de comercialização (mundiais e nacio- 
nais) de cada um dos modelos, para cada uma das 
gamas. Na segunda grelha pretendeu-se saber os 
preços de venda, aluguer e manutenção. 

Conforme referimos noutro local, da lista inicial de 
representantes nacionais de computadores respon- 
deram os seguintes: BURROUGHS, CMC, DATA 
GENERAL, DATINFOR, IBM, ICL, NCR, OLIVETTI e 
REGISCONTA. 

Apresentamos, de seguida os elementos obtidos. 


2.1 Características de hardware e software 
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Burroughs 


I - DESIGNAÇÃO DO SISTEMA II - DESIGNAÇÕES DOS MODELOS (até 4 modelos) : 
Pee care en, CEPA SS ASTEDARES COR PIPETTES 5025277 


III - DATAS DE COMERCIALIZAÇÃO A NÍVEL MUND 
EE TE E 


ABR 76 MAI 78 DEZ 79 OUT 80 


V - CARACTERÍSTICAS SUMÁRIAS DO SOFTWARE DE BASE 
Densree=eegladãa 22 Jasmuols bo oneendinovel | -nlnsy: Afeiiedanh Dir alo qria 
MCP - MASTER CONTROL PROGRAM 
STORE DER MEM. VIRTUAL - ALOCAÇÃO DINÂMICA RECURSOS - MULTIPROGRAMAÇÃO 
co COBOL - RPG = NDL - MPL 
COMPILADORES DISPONIVEL crrADORES (REP.MRITER) (AUDIT ENTRY), ETC. 


VI - FORMAÇÃO 


TIPO DE CURSOS [o DESTINATÁRIOS RAÇÃO GORSS) 


Introdução a Sistemas Aja 


8 
0 
Program. /Analistas 


Program. /Analistas inbrmi cole rdhçã. 7] 


30/cada 


Programação COBOL 
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I - DESIGNAÇÃO DO SISTEMA II - DESIGNAÇÕES DOS MODELOS (ate 4 modelos) 
RREaaro SD 


iSRARES: GR EESC SRA OE EIS 
. BI-PROCESSADOR 
III - DATAS DE COMERCIALIZAÇÃO A NÍVEL MUNDIAL E À NIVEL NACIONA 


JAN 80 MAI 80 JAN MAI 80 JAN 80 MAI 80 


IV - CARACTERÍSTICAS ÁRIAS DO HARDWARE 


Da ne oa Enntasgatnmos hagaanon = censo 


| 


EE ço 
ec 
a ma a SO 
PRECES ee ia O 
Pos a a] 
aço O ea 
andando Sos clean iii Sia 
ES E E RR 


V - CARACTERÍSPICAS SUMÁRIAS DO SOFTWARE DE BASE 
e 
man dos SRS SOS E DS : 

SISTEMA OPERATIVO MCP - MASTER CONTROL PROGRAM 
LADO qd COBOL 68; COBOL 74; FORTRAN IV; FORTRAN 77 
CMEI RES DISPONÍVEIS BASIC - INTERACTIVE BASIC - UPL - NDL -. SDL 


DMS TI 
S.G.B.D. DISPONÍVEIS DMS INQUIRY 


VI - FORMAÇÃO 


(*) Compatíveis ao nível de Código os mesmos devices 
(**) REPORT. WRITER / DATA ENTRY / MODELO DE SIMILAÇÃO / ETC. 
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CM 


PORTUGAL 


I - DESIGNAÇÃO DO SISTEMA “II - DESIGNAÇÕES DOS MODELOS (atê 4 modelos) 
DERA TE SENSE amido 
SÉRIE CMC 70 7020 


III - DATAS DE COMERCIALIZAÇÃO A NÍVEL MUNDIAL E À NÍVEL NACIONAL 
"""—————— 
PESC RETAS + ES 7 ERR 5 TO 


1981 1981 1980 1981 1980 1981 ESSA 


o EST O 11 
A <i ioo DORSO RS DOR LG BR 
: 


(KBytes) 


(5+5) (5+5) 20 (10+10) 
CRT's n.(Unid.) 1(1920 car. 1(1920 car.) 1(1920 car.) 
(Unid.) 


Ea PE MAO Ma cr 
E CEO rs 
E O MID ELSE RAD 
PERIFÉRICOS Diskette | (1042) 5 (1002) 5 
(Mp Bite peifm em mossi 


V - CARACTERÍSTICAS SUMÁRIAS DO SOFTWARE DE BASE 
arado] O Mie Pedi ena | TO ooo = enspelonil ca-tegreaail 


SISTEMA OPERATIVO RECAP. RECAP. 


O EE 
VI - FORMAÇÃO 


EEE nene 
RECAP/OPERAÇÃO PERA Gi Jor sta + iomtehan ça 
Em ao Pot igelimas 
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I - DESIGNAÇÃO DO SISTEMA II - DESIGNAÇÕES DOS MODELOS (até 4 modelos) 


SÉRIE CMC 7000 E Mt À 


- 


ax. (Uni 


Multitask 
Ega 
POMPILADORES DISPONÍVEIS COBOL ANSI 74 

TAL 2000 
S.G.B.D. DISPONÍVEIS BED anEa Guta 


VI - FORMAÇÃO 


TIPO DE CURSOS DESTINATÁRIO 
[Muititask Operating System 
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| € DataGeneral 
FESARSaA RSI) a Anjos | ae mm 


€s/10 CS/50 CS/70 


I - DESIGNAÇÃO DO SISTEMA 


CS - COMMERCIAL SYSTEM 


III - DATAS DE COMERCIALIZAÇÃO A NÍVEL MUNDIAL E A NÍVEL NACIONAL 


1981 1981 1980 1980 1981 1981 


RE TERES RES 0 ET pq 
: 1 


PERIFÉRICOS 
(S/N) 


V - CARACTERÍSTICAS SUMÁRIAS DO SOFTWARE DE BASE 
Fat Srs = E SM DRT 2 MRS a TE: MRE ET 
SISTEMA OPERATIVO ICOS ICOS ICOS rece 

q COBOL/BUSINESS | COBOL/BUSINESS | COBOL/BUSINESS Essa 


V 

CURSO DESTINATÁRIO | DURAÇÃO (HORAS) | 
TODS USER 
COBOL Extensões 1COS 


I - FORMAÇÃO 


(**)2 de sistema 
1 por cada CRT E lia 


(*)1 de sistema 
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e un AR 1 e 7 a 
C/150 C/350 MV/6000 Mv/8000 


I - DESIGNAÇÃO DO SISTEMA TI - DESIGNAÇÕES DOS MODELOS (até 4 modelos) 
A AR 
ECLIPSE' 


III - DATAS DE COMERCIALIZAÇÃO A NÍVEL MUNDIAL E A NÍVEL NACIONAL 
E Eee E 


1980 1980 1979 1979 1981 1981 


IV - CARACTERÍSTICAS SUMÁRIAS DO HARDWARE 


VI - FORMAÇÃO 
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SISTEMA OPERATIVO 


TOMPILADORES DISPONÍVEIS 


S.G.B.D. DISPONÍVEIS 
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I - DESIGNAÇÃO DO SISTEMA II - DESIGNAÇÕES DOS MODELOS (atê 4 modelos) 
Benta ni 1, 7 sp ag pr O E E E 


III - DATAS DE COMERCIALIZAÇÃO A NÍVEL MUNDIAL E A NÍVEL NACIONAL 


Min (Bytes) n(KBytes) 


SUMÁRIAS DO SOFTWARE DE BASE 
Ee = E ERG = 2 See ar Te qe 
BASIC / psi FORTRAN / RPG II 


VI - FORMAÇÃO 


À PO Te on OA DESTINATÁRIO 


Administradores de Sistemas 


Analistas/Programadores 
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istem 90 modelos dife ; des" Ee 
as no mo jo us talaanes As alterações-do modelo são 


I - DESIGNAÇÃO DO SISTEMA II - DESIGNAÇÕES DOS MODELOS (ate 4 modelos) 
E ss 
34 


III - DATAS DE COMERCIALIZAÇÃO A NÍVEL MUNDIAL E A NÍVEL NACIONAL 


ABR 77 


VI - FORMAÇÃO 


Operadores para Recolha de Dado 
Programadores de Sistema 


OBS: A IBM dispõe dum vasto "PROGRAMA DE EDUCAÇÃO MODULAR" constituído por cursos (segmentos) 
agrupados por três grupos: Sistemas Intermédios e Grandes. Pequenos Sistemas e Cursos 
de interesse comum. Os quatros segmentos acima indicados fazem parte do primeiro grupo 


que ê constituído por 27 segmentos. 
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I - DESIGNAÇÃO DO SISTEMA II - DESIGNAÇÕES DOS MODELOS (ate 4 modelos) 


sete terend Dofa trade RAR PHS ROL SNS MES FO DP 


= 


AS TEE  mes em 


º 2 (de linhas, para impressoras matriciais o limite teórico & 253) 
Ti OS A AR AT O DE AO Ci orla PODRES 


Leitor/Perfurador de cartões de 96 colunas 


EA 
S.G.B.D. DISPONÍVEIS 
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COMPUTADORES 
LIMITADA 


I - DESIGNAÇÃO DO SISTEMA II - DESIGNAÇÕES DOS MODELOS (até 4 modelos) 


ICL SYSTEM 25 


1000 
130+130 


5+130 
1000 


So 


ee To a? 
V) 


V - CARACTERÍSTICAS SUMÁRIAS DO SOFTWARE DE BASE 


S IME III 
IAS 
O 


O ASSEMBLER, COBOL, RPG II 


VI - FORMAÇÃO 


TIPO DE CURSOS [DESTINATÁRIOS IRA (HORAS) | 
Plamed Careers or A | 


Obs. Esta empresa entregou um esquema de "Planned Carrers" que pela sua extensão não pode 
ser publicado. 
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Ed é 8 
olivelti 
EEE De o Re 
CASE: 


ai 
Mon | Mão np sis 


V - CARACTERÍSTICAS SUMÁRIAS DO SOFTWARE DE BASE 


dennimmgei ini mc, onda Ta Ga ONT 
SISTEMA OPERATIVO COSMOS-DOS COSMOS-DOS 


OMPILADORES DISPONÍVEIS ASSEMBLER, PL 1| ASSEMBLER, PL 1 
EE DS RR 


VI - FORMAÇÃO 
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I - DESIGNAÇÃO DO SISTEMA - 


NCR I - 9000 e V-8000 


III - DATAS DE COMERCIALIZAÇÃO 
EEE SE TO 


1982 1982 1979 


100000 : . 

20 linhas integ. [20 linhas integ. 
multiplexor +253/multinlexor 

300LPM (1) 


cais same PER RC E SS O o a 1 E ces 
IRX - Interact. | VRX - Virtual VRX - Virtual 
SISTEMA OPERATIVO Resource Execut | Resource Execut. Resource Execu: 
LADO COBOL COBOL, RPG, NEAT| COBOL, RPG, NEA asconcaieaaa 
di do is A FORTRAN, BASIC | FORTRAN, BASI 


VI - FORMAÇÃO 


TIPO DE CURSOS 
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I - DESIGNAÇÃO DO SISTEMA II - DESIGNAÇÕES DOS MODELOS (ate 4 modelos 


E ES PST 
NCR I - 9000 


IV - CARACTERÍSTICAS SUMÁRIAS DO HARDWARE 
== = TSE a Ud = 


linhas integr 
multiplexor 


ax. (Unid.) 900LPM 
S 
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II - DESIGNAÇÕES DOS MODELOS (ate 4 modelos) 


I - DESIGNAÇÃO DO SISTEMA 
EE e “e ae arg 
mom | me [O] 


VI - FORMAÇÃO 


TIPO DE CURSOS DESTINATÁRIO ÃO (HORA 


adore Programadore x ore 
ama 


Programação Cobol Proramadas  LLLLD]DWA 
Utilitários do Sistema 


TE | + 
E 
o 


70 
O 
+ 35 
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I - DESIGNAÇÃO DO SISTEMA II - DESIGNAÇÕES DOS MODELOS (até 4 modelos) 
ET ESP RCUDE SO OT STEudda [EU Cga = 


III - DATAS DE COMERCIALIZAÇÃO A NÍVEL MUNDIAL E A NÍVEL NACIONAL 


SISTEMA OPERATIVO 


| 


RAÇÃO 
4 


+ E 


0 


70 
30 
35 
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2.2 Preços das configurações standard 


Para as duas configurações «standard» adiante C — Custos de manutenção (contos/ano); 
descriminadas pediu-se: D— Taxa de câmbio do dólar americano ou de 
| B — Preço de aluguer e tipo de aluguer (contos! | E — Percentagem de despesas de importação (ta- 
| ano); xas, impostos, transportes, etc.): 


| Burroughs 


| DSK-80MB fixo 
| LP - 250 LPM 
CRT =5 

COBOL COMPILER 


CPU-B1955 
MEM-1024KB 
MT-2 UNID 
CRT-25 
LP-2x1000LPM 
COBOL 
DSK-1200MB 


MODELO 7030 


DSK-75MB 

CRT's-5 

LPT-1 de 250LPM 
Compilador-COBOL 


LPT's-2 de 1000LPM 
Compilador-COBOL 


60 “Vol. 4, Nº 2 INFORMÁTICA 


Data General 


Configurações 


315 1US$= a 


(*) O, cliente pode optar vela compra durante a vigência do contrato. 


DSK-75MB 
CRT's-5 
LPT-1 de 250 LPM 
Compilador-COBOL 


Aluguer mensal 
em contrato 


DSK-1000MB 
TP-2 Unidades 
CRT's-25 

LPT's-2 de 1000 LPM 
Compilador-COBOL 


Datinfor 


HARDWARE 
CPU c/256KB 
1 Unidade Diskette 308KB 
1 Unidade Disco 90MB 
(75 fixos+15 amovíveis) 
5 CRT (24x80) 
1 Impressora 250LPM q 
SOFTWARE 6 832 3 054 546,56 |US$=70800 154 
S. OPERATIVO 
DMS (Data ERR 
System) 
Assembler 
Cobol 
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Datinfor 


Configurações 


30 123 | 13465 | No minimo de 
2 anos 


Aluguer mensal|Não Aplic. 


HARDWARE 

CPU de 1024KB 

4 Unidades disco 288MB 
cada (amovíveis) 

2 Unidades banda magnê 
tica 1600BPI 9 pistas 
compatível IBM 

1 CRT(24x80) c/Unidade 
de diskette integrada 

p4 CRT (24x80) 

2 Impressoras 1100LPM 


SOFTWARE 
S.Operativo 

DMS (Data Management 
Syst.) Cobol Assembler 


US$=70$00 


Configurações 


DSK-75MB 
CRT's-5 
LPT-1 de 250LPM 


408,96 | £ 129,00 
Anual 


16 500 - 410 Aluguer/5 anos|- 125 £ 129,00 


Não Aplicável 14,2 luguermenda lie. 
30 / 40 
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(COBOL-Compilation/ 
/Development ) 


Não Aplicável 


(Sftw.Base) Aluguer mensal|Não Aplic. 


Não Aplicável 


DSK-1000MB 
TP-2 Unidades 
CRT's-25 

LPT's-2 de 1000LPM 


(COMPILADOR COBOL) 
(Sofware Base) 


inquérito equipamentos 


IBM 


Configurações 


SISTEMA 4341 
MODELO MOZ 
CPU c/256KB 
3279 CONSOLE A CORES 
LPT-2 (2000LPM) 
DSK-16 UNIDADES COM 
13,115GB 
DISKETTE-1 
TP-4(tipo 3420-006) 
CRT's-50 (3277-002) 


= 


SISTEMA 34 D15 
UCP-96KB 

DSK-128,4MB 
1 DISKETTE 2 719+182 
LPT-300LPM (182-Soft .) 
CRT's-5 


SUPPORT PROGRAM: 5726- 
551 


2 421 - 


(Soft .não 
indicado) 


5726-CBl COBOL 


SISTEMA 38 MODELO 562 
UCP-1536KB 


indicado) 


CRT's-5 
LPT-1 de 250LPM 
Compilador - COBOL 


9H: 
Has 
“Ph 
ul 

di ad ms 
4 
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Regisconta 


Configurações 


DSK-1000 MB 
TP-2Unidades 
CRT's-25 

LPT's-2 de 1000LPM 
Compilador - COBOL 


3. CONSIDERAÇÕES FINAIS 


Como se pode verificar pela análise detalhada das 
respostas, ficaram por abordar algumas questões 
cruciais para a obtenção dum juizo de valor das 
várias marcas. No entanto, o nosso objectivo não é 
tanto permitir a formulação desse juizo (o que carece 
duma abordagem mais profunda e sistemática) mas 


Vol. 4, N.º 2 


22 000 8 700 


Mínimo 36 
meses com 
opção de 
compra 


3::950 SK.12,00 


sim, apresentar alguns dos principais instrumentos 
que são, ou podem vir a ser, utilizadas na informá- 
tica da gestão. Neste contexto, a análise crítica das 
respostas não faz, aqui, qualquer sentido limitando- 
-nos apenas à sua divulgação. Pensamos, com efei- 
to, que os fornecedores devem ter direito à apresen- 
tação dos seus próprios produtos e fazemo-lo sem 
poi ne tipo de «complexo publicitário» ou de outra 
ordem. 
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Você precisa 
de uma . 
grande memória! 


“COMPUTADOR 
ERICSSON 


TEM A MEMÓRIA DE QUE VOCÊ PRECISA 


HARDWARE e 64 terminais locais e/ou SOFTWARE 
e De 10 a 880 m em memória remotos e «Packages» portugueses 
de massa e Bandas magnéticas e de fábrica para as 
e Impressoras de 120 CPS e Multiprocessamento diferentes aplicações 
até 600 LPM e multiprogramação 
(tempo real) 


LISBOA € PORTO € COIMBRA 6 FARO 6 LEIRIA € BRAGA € FUNCHAL € PONTA DELGADA 
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A EXPERIÊNCIA CONTA! 


A nossa equipa de especialistas em microcomputadores, 
pode provavelmente, oferecer-lhe muito mais anos 
de experiência do que qualquer outra, neste sector. 
A certeza de um investimento seguro 
apoiado numa experiência comprovada 
é o que mais conta 
para os nossos clientes. 

Também V. pode dispôr desta garantia 
que lhe oferecemos 
com um serviço completo e permanente de: 
Análise e Programação, de Formação e de Assistência. 


A SOLUÇÃO DO SEU PROBLEMA 
ESTÁ NAS SUAS MÃOS! 


CONSULTE-NOS! 


divisão de 


PAPA io 


ANTÓNIO PACHECO AGOSTINHO, LDA. 
RUA RODRIGUES SAMPAIO. 15-2.º TELEF. 578093 (PPCA 8 LINHAS) 
1199 LISBOA CODEX-PORTUGAL ' TELEX: 15645 APAL P-TELEG.: ANTOCOPA 
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O software de aplicações 
e as transformações 

nas organizações. 
Considerandos sobre a represen- 
tação do conhecimento 


RESUMO É examinado um aspecto do efeito 
da tecnologia da informação sobre a 
capacidade das organizações em se 
adaptarem e em mudarem. 


ABSTRACT It is examined one aspect of the ef- 
fect of information technologies on 
the organization's ability to adapt 
and change. 


1. O PROBLEMA: SOFTWARE PARA RESPON- 
DER ÀS TRANSFORMAÇÕES NAS ORGANI- 
ZAÇÕES. 


E do senso comum que qualquer organização 
para poder sobreviver deve adaptar-se às mudanças 
que ocorrem no ambiente em que estão inseridas. 
Aquelas que o não conseguem são, inevitavelmente, 
forçadas a abandonar o mercado, se são empresas 
que operam no mercado competitivo; têm os seus 
orçamentos cancelados, no caso de serem empre- 
sas públicas; ou são derrubados, no caso de se 
tratar dos próprios governos. 

A forma como deve ser concebida uma organiza- 
ção para responder à mudança é, concerteza, uma 
matéria bastante difícil, e tem sido o objecto de 
muitos livros da Teoria das Organizações. 

O que eu desejo examinar aqui é um dos aspec- 
tos do problema que parece ter sido negligenciado, 
trata-se do efeito da tecnologia da informação sobre 
a capacidade de adaptação à mudança das organi- 
zações. 

Certamente que há numerosos casos onde a im- 
plementação dum sistema de informação aumentou 
a flexibilidade da organização. Por exemplo, a utiliza- 
ção duma base de dados centralizada pode permitir 
o acesso e a combinação de dados sob uma varie- 
dade de modos praticamente impossível quando os 
dados estavam arquivados em ficheiros manuais es- 
palhados pela empresa. 

A flexibilidade de uma determinada aplicação de- 
pende, obviamente, da capacidade de previsão dos 
seus conceptores. Para este fim, na formação dos 
analistas programadores é geralmente aconselhada 
a visualização da definição mais vasta do problema 
para que os programas possam solucionar não só o 
problema imediato mas também as possíveis varian- 
tes que possam aparecer. 

Esta estratégia tem limitações evidentes. Pro- 
curando alcançar uma solução generalista, o infor- 
mático pode desperdiçar muito tempo para obter 


Ronald M. Lee 
HASA 


soluções de casos que, na realidade, poderão nunca 
chegar a ocorrer. Ele(a) deve além disso, determinar 
a flexibilidade da codificação na lógica do programa. 
Referirei o nível da flexibilidade adoptado como a 
«flexibilidade intencional» do sistema. 

A selecção do nível adequado de flexibilidade in- 
tencional é, contudo, difícil e, quase certo, novas 
solicitações não previstas aparecerão mais tarde, 
obrigando a modificações nos programas. É aqui 
que o problema surge. 

Qualquer pessoa que tenha escrito mesmo um 
pequeno programa, sabe que é' muito mais fácil in- 
corporar uma determinada condição na lógica inicial 
do programa do que adicioná-la mais tarde. Esta 
dificuldade cresce exponencialmente com a comple- 
xidade do programa ou do sistema. (Por «sistema», 
entendo uma colecção de programas e ficheiros com 
funções interdependentes). Na verdade, o custo e o 
esforço para modificar tais sistemas excedem, mui- 
tas vezes o despendido com o desenvolvimento ini- 
cial. Por exemplo, (Wulf, 1977) refere-se à: 


«extrema dificuldade que se encontra para 
modificar um programa. Embora, frequente- 
mente, acreditemos saber o que necessita- 
mos em termos de software, especificando-o 
com precisão, parece ser verdade que, após 
o obtermos sabemos ainda mais e desejaría- 
mos modificá-lo. Um exame do historial de 
quase todos os maiores sistemas de soft- 
ware, mostra que tão cedo eles começam a 
ser utilizados, tão cedo começarão a ser mo- 
dificados! A evolução apenas pára com a 
morte do sistema. O custo de tal evolução 
quase nunca é avaliado mas, pelo menos 
num caso, ele excedeu o custo do desenvol- 
vimento inicial em cem vezes mais.» 


A alteração do sistema não é apenas cara, é tam- 
bém arriscada. (De Millo, et al, 1979) salientaram: 


«cada programador sabe que alterando uma 
linha, ou algumas vezes até um bit, pode 
destruir completamente um programa ou mu- 
tilá-lo de forma que nós não entendemos e 
que não podemos prever...» 


Na verdade, para além da despesa e do risco, 
parece existir um limite para o número de modifica- 
ções que estes sistemas podem admitir. (Winograd, 
1979) lembra: 


«Utilizando as técnicas correntes na progra- 
mação, os sistemas atingem muitas vezes 
um ponto onde o acréscimo de alterações 
torna a sua estrutura tão barroca e opaca 
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que posteriores alterações são impossíveis, 
e a performance do sistema é irreversivel- 
mente degradada.» (p. 392) 


' Para resumir, o problema base dos sistemas de 
aplicações correntes é que eles são «quebradiços», 
isto é, não podem ser reformulados facilmente com 


vista à sua adaptação às alterações no seu meio . 


envolvente. Esta fragilidade tem consequências tanto 
mais profundamente desestabilizadoras quanto maior 
for o número de empresas desde as pequenas e 
médias até aos imensos departamentos governa- 
mentais que convertem os seus tratamentos da infor- 
mação para o software dos computadores. Os ga- 
nhos inerentes ao aumento da eficiência e da veloci- 
dade dos processamentos, são claros (ou o investi- 
mento não teria sido justificável). 

Contudo, podem existir no longo prazo, grandes 
desperdícios de custos, até que a empresa encontre 
a sua capacidade de adaptação ao ambiente onde 
vive, devido à incapacidade de modificar o sistema 
de informação em consonância. 


2. OUTRO PROBLEMA: A TRANSPORTABILI- 
DADE DO CONHECIMENTO 


Usarei o termo «sistema de aplicações» (ou, algu- 
mas vezes, simplesmente «aplicação») para referir 
um sistema automático composto de vários progra- 
mas e ficheiros de dados, os quais juntos executam 
algumas tarefas duma organização — e.g. processa- 
mento de ordens de venda, controlo de stocks, etc. 
A atenção será, por conseguinte, sobre o software 
que suporta as tarefas duma empresa e não, e.g., 
sobre o sistema de operação que suporta as opera- 
ções internas do computador. 

O software deste tipo de aplicações é, na maioria 
dos casos, desenvolvido no interior de cada empresa 
através da sua Direcção de Informática. Mais impor- 
tante ainda, estas aplicações são tipicamente escri- 
tas a «partir do nada». O mesmo é dizer que elas 
não usam código de programa previamente desen- 
volvido adequado ao domínio da aplicação. 

A excepção é o uso de «packages» de programas 
e, eventualmente de rotinas pré-escritas que o novo 
programa pode chamar no ponto apropriado. 

Assim, existem numerosos «packages» para análi- 
se estatística e algoritmos quantitativos que são usa- 
dos frequentemente em aplicações científicas. Do 
mesmo modo, existem «packages» para tarefas ad- 
ministrativas como processamento de salários, con- 
trolo de stocks, etc. Esta última classe de software 
pré-escrito tem, contudo, alcançado menos sucesso. 

O problema tem a ver, uma vez mais, com a 
«flexibilidade intencional» do «package». Nas aplica- 
ções científicas, o contexto no qual uma análise par- 
ticular ou um algoritmo é usado é relativamente es- 
pecificado. Por exemplo, em qualquer aplicação dum 
algoritmo de programação linear devemos especifi- 
car a função objectivo, as restrições e os coeficien- 
tes tecnológicos e recebemos, como resultado, os 
valores das variáveis de decisão. Contudo, para a 
maioria das aplicações de gestão, os problemas são 
menos normalizados. Provavelmente o mais regular 
destes é o processamente de salários, mas mesmo 
aí, existem diferenças apreciáveis duma organização 
para outra sobre os abonos a adicionar, as dedu- 
ções automáticas, classsificações do trabalho, etc. 

Para ser possível utilizar «packages» em tais apli- 
cações, as características particulares das organiza- 
ções devem cair dentro da flexibilidade intencional 
do «package». Quando isto não acontece, a Direc- 
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ção de Informática pode, algumas vezes tentar modi- 
ficar o «package». No entanto, a experiência acon- 
selha a que se re-programe tudo a partir do nada, 
por ser muito mais fácil. 

Referirei este aspecto do desenvolvimento do soft- 
ware de aplicações como problema da «transporta- 
bilidade do conhecimento» duma aplicação para ou- 
tra. Como observei, o problema é geralmente do tipo 
«ou tudo ou nada». Somente no caso em que uma 
parte do conhecimento dum sistema ou programa 
corresponde a um programa ou a uma subrotina é 
que é possível a sua transportabilidade. Parece não 
existir meio termo, onde se poderia utilizar uma parte 
arbitrária duma função dum programa no desenvolvi- 
mento de uma outra. 

A consequência disto é que o software para o 
tratamento da informação duma organização, não 
evolui de forma harmoniosa; não evolui naturalmente 
das experiências anteriores. Assim, por exemplo, 
após um quarto de século de processamento auto- 
mático dos salários, as empresas continuam ainda, 
na maioria dos casos, a ter que escrever novos 
programas de salários. 

Por contraste, o conhecimento na forma de espe- 
cialização humana é facilmente transportável. Por 
exemplo, quando a empresa X emprega um novo 
contabilista, é duvidoso que o sistema contabilístico 
dessa empresa se ajuste à experiência ou à forma- 
ção do novo empregado. Contudo desde que ele(a) 
seja razoavelmente competente, e após um breve 
período de ambientação, poderá adaptar-se ao novo 
sistema após um período curto de orientação. 

A situação com o software de aplicações implica 
uma completa re-educação começando pela escola 
secundária. 

Deixem-me, nas linhas seguintes, fazer o resumo 
dos meus argumentos. A minha tese é que existe 
um problema fundamental na arquitectura básica dos 
sistemas de aplicações, nomeadamente eles são 
muito «cristalizados» e resistentes à mudança. Para 
mim, isto tem duas importantes consequências. 
Uma, como foi focado na última secção, é que à 
medida que uma empresa se torna dependente do 
seu sistema de informação, mais ela própria se cris- 
taliza e se torna incapaz de responder facilmente à 
mudança. A outra consequência, o tema desta sec- 
ção, aplica-se não só às empresas individuais como 
também a todo o sistema da tecnologia da informa- 
ção: a arquitectura do software corrente não propor- 
ciona um enquadramento apropriado para a resolu- 
ção do problema da evolução gradual do cresci- 
mento. Somos, repetidamente, forçados a re-inventar 
a roda. O Progresso (tão pouco tem sido) tem-se 
traduzido no facto de aparecer alguém com uma 
roda maior que as existentes. O desperdício de capi- 
tal e recursos humanos não é senão uma pequena 
parte do problema. A maior dificuldade é que quando 
alguém encontra um método melhor para uma tarefa 
administrativa, esse avanço não pode ser dessimi- 
nado para o software das tarefas correlacionadas. 
Desta forma, a indústria do desenvolvimento de soft- 
ware de aplicações não pode crescer por forma a 
acompanhar as evoluções encetadas e está, conti- 
nuamente, a recomeçar a partir da base. 

Nesta secção, em seguida, examino as razões 
técnicas que explicam porque é que os sistemas de 
aplicações são tão cristalizados. Vejo isto como es- 
tando, intimamente relacionado com dois aspectos: o 
primeiro decorre da forma como a lógica dos progra- 
mas é estruturada; o. segundo da forma como os 
dados são organizados no ficheiro e nas bases de 
dados. Uma arquitectura alternativa para o software 
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de aplicações que evite estes problemas embora 
não sem certos custos, será proposta. 


3. O PROBLEMA COM OS PROGRAMAS: LIN- 
GUAGENS DE PROCEDIMENTOS VS. SISTE- 
MAS DE PRODUÇÃO. 


As asserções numa linguagem de programação 
são feitas sobre a forma de ordens (commands) para 
a máquina — i, e. «add this», «move this data from 
here to there», «print this on the terminal», etc. 

Um programa é assim uma sequência de tais as- 
serções, e.g. 


10º PESA 
Caco bi A dm 
SO EE NE 
40 PRINT Z 


Aqui, as asserções foram numeradas para fins de 
identificação. De salientar que a ordenação das as- 
serções neste programa indica a sequência sob a 
qual as ordens devem ser executadas pela máquina. 

Esta sequência linear de execução pode ser modi- 
ficada por as chamadas «asserções de controlo». 
Considere, por exemplo, o programa: 


10 LET X = 0 

20 ADD 1 TO X 

30 PRINT X 

40 IF X = 100 GO TO 60 
50 GO TO 20 

60 STOP 


Quando este programa estiver concluído foram im- 
pressos os números desde 1 até 100. Aqui, as as- 
serções 40 e 50 são de controlo. Na asserção 40, se 
X for igual a 100, o programa desencadeia a asser- 
ção 60 onde pára. Por outro lado, a asserção 50 
direcciona o programa para a asserção 20 onde X é 
novamente incrementado, impresso, etc. 

Assim, a sequência de execução em tais progra- 
mas segue normalmente, a sequência das asser- 
ções, excepto quando entra em contradição com as 
acções enunciadas pelas asserções de controlo. 

Às linguagens deste tipo são denominadas proce- 
dimentais. Estas são, basicamente, o único tipo 
usado nas aplicações comerciais e incluem todas as 
linguagens bem conhecidas para processamento de 
dados e aplicações científicas — e.g., COBOL, FOR- 
TRAN, PL/1, BASIC, ALGOL, etc. 

Nestes casos, o conhecimento encerrado no pro- 
grama é expresso através dos passos específicos à 
sua concretização. Uma ideia chave a reter é que 
esta forma de organização com base em procedi- 
mentos torna as asserções dos programas inter- 
“dependentes. Geralmente (embora nem sempre) al- 
terar a ordem de um qualquer par de asserções 
implica sérias alterações para as operações do pro- 

rama. 
q Embora possa não ser óbvio pelos dois pequenos 
exemplos, é esta inter-dependência que torna os 
programas tão difíceis de modificar. 

Como resultado de uma interessante mistura entre 
a informática e a linguística, emergiu, na última dé- 
cada, uma via alternativa. Esta via é baseada nos 
denominados «sistemas de produção» (SP) que pos- 
sibilitam a expressão do conteúdo dum programa 
independentemente da sua sequência de execução. 

O conceito de sistemas de produção foi proposto 
em primeiro lugar pelo linguísta Post em 1943 como 
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ajuda à especificação formal da linguagem natural. A 
ideia base é extremamente simples. Uma única pro- 
dução é uma regra com a seguinte forma: 


IF < condição > THEN < acção > 
ou, numa notação mais usual, 
< condição > => < acção > 


Um sistema de produção consiste numa «base de 
dados» e numa colecção de tais regras de produção. 
(Isto é a base de dados num sentido muito restrito, 
não devendo ser confundida com aquelas cuja ma- 
nutenção é assegurada por um sistema de gestão 
de base de dados). 

A forma em cada regra é uma condição a ser 
combinada pela base de dados, e a acção é tipica- 
mente uma modificação à base. Na forma mais pura 
dos sistemas de produção as regras são arrumadas 
linearmente. Começando a partir do início as condi- 
ções são lançadas na base de dados até que uma 
combinação bem sucedida seja encontrada. 

A acção correspondente é então desencadeada 
sendo o processo repetido novamente desde o 
início. 

Considere o seguinte exemplo, para reconheci- 
mento dum certo tipo de expressões declarativas da 
língua inglesa. 


THE — DET 

ON — PREP 
HUNGRY — ADJ 
BIT > VT 

DOG > N 

CAT > N 

NECK —» N 

N > NP 

ADJ NP — NP 
10 DET NP > NP 
11 PREP NP > PP 
12 VT NP > VP 
13 VP PP > VP 
14 NPVP>S 


O lado esquerdo das regras de produção repre- 
senta um léxico indicando as categorias gramaticais 
de várias palavras. O lado direito das regras indica a 
gramática apropriada. Quando o símbolo terminal 
«S» é alcançado a frase é aceite como fazendo 
parte da gramática. Assim, suponha que tem a se- 
guinte frase: 


«The hungry dog bit cat on the neck» 
Isto é analizado da seguinte maneira: 


DET ADJ N VT DET N PREP DET N Rutes 1=7 
DET ADJ NP VT DET NP PREP DET NP. 3 x rule 8 
DET NP VT DET NP PREP DET NP 1 x rule 9 
NP VT NP PREP NP 3 x rule 10 

k 

1 

1 


SONDA BIN — 


NP VT. NP PP c rule 11 
NP VP PP x rule 13 
Ss rule 14 


As aplicações iniciais dos sistemas de produção 
foram implementadas na área da teoria dos compila- 


69 


o software de aplicações 


dores i.e., especificando a síntaxe e a interpretação 
das linguagens de programação (como opostas às 
linguagens naturais). Posteriormente, tem vindo a 
ser reconhecido que os SP têm um campo de aplica- 
ção muito mais vasto. Por exemplo uma plicação 
clássica foi o sistema «Logical Theorist» (Newell, 
Shaw e Simon, 1963). Começando com os axiomas 
iniciais e as regras de inferência da obra de Russel 
e Whitehead «Principa Mathematica» o «Logical 
Theorist» provou duma forma bem sucedida todos 
os teoremas daquele livro. Na verdade, em vários 
casos foram demonstrados teoremas duma forma 
mais simples que na obra original. 

Outro famoso exemplo do uso dos sistemas de 
produção foi o sistema MYCIN (Shortliffe, 1976). O 
objectivo do MYCIN é realizar diagnósticos médicos. 
Neste caso, a base de dados é constituída por os 
sintomas do doente revelados por vários testes la- 
boratoriais e por outros meios. As regras de produ- 
ção são, assim, o conjunto das deduções que um 
médico pode fazer baseado nos sintomas detecta- 
dos. Na área da Inteligência Artificial (IA) foram ex- 
ploradas também outras aplicações dos sistemas de 
produção. (Davis e King, 1975), num excelente artigo 
sobre sistemas de produção comentam sobre o tipo 
de aplicações onde os SP são mais adequados: 

... onde o enfâse duma tarefa é o reconhecimento 
dum grande número de estados distintos, os SP têm 
vantagem. Numa aproximação orientada por uma 
concepção apoiada em procedimentos é difícil de 
organizar e de actualizar as repetidas verificações 
dum grande número de variáveis de estados e a 
correspondente transferência de controlo... 

(os SP são) caracterizados pelo princípio que 
«qualquer regra pode ser accionada em qualquer 
momento», o que põe o enfâse no facto de que em 
qualquer ponto do tratamento automático, qualquer 
regra pode, potencialmente, ser a seguinte a ser 
seleccionada, dependendo apenas do estado da 
base de dados no fim do ciclo corrente. Compare 
isto à situação normal numa linguagem apoiada em 
procedimentos, onde tal princípio é manifestamente 
falso: qualquer procedimento do programa podia po- 
tencialmente, ser o próximo a ser chamado, depen- 
dendo do conteúdo da base de dados. Os SP são, 
além disso, úteis onde é importante detectar e tratar 
com um grande número de estados independentes 
num sistema que requer grande atenção e capaci- 
dade de resposta a pequenas mudanças. 

Sobre a facilidade de modificações dos SP conti- 
nuam os autores (p. 20): 


Pode-se considerar a modularidade dum 
programa como o grau de separação das 
suas unidades funcionais em peças isoladas. 
Um programa é altamente modular se qual- 
quer unidade funcional pode ser modificada 
(adicionada, suprimida ou reactividada) sem 
modificação prévia das outras unidades fun- 
cionais. Deste modo, a modularidade é in- 
versamente proporcional à dependência en- 
tre as várias unidades funcionais. 

A modularidade dos programas escritos 
como sistemas de produção puros deriva do 
facto de que a chamada da regra seguinte é 
determinada somente pelo conteúdo da base 
de dados e nenhuma regra é alguma vez 
chamada directamente. Assim, a adição (ou 
supressão) duma regra não requer a modifi- 
cação de qualquer outra para a sua adição 
ou supressão. Isto pode ser demonstrado re- 
tirando sistematicamente regras do SP: mui- 


tos sistemas continuarão, até um certo 
ponto, a mostrar um comportamento aceitá- 
vel. Pelo contrário, a adição dum procedi- 
mento num programa ALGOL requer modlifi- 
cações noutros pontos do seu código para 
se a segurar a sua correcta utilização, en- 
quanto que a supressão arbitrária dum pro- 
cedimento irá, em geral, danificar o próprio 
programa. 

Assim, enquanto que um programador de 
ALGOL deve escolher cuidadosamente as 
ordens de chamada do procedimento para 
criar uma determinada sequência de situa- 
ções, num sistema de produção são, exacta- 
mente, as situações que determinam a pró- 
xima regra a ser invocada. E como a regra 
somente pode ser escolhida se o seu critério 
de relevância for encontrado, a escolha con- 
tinua a ser plausível e o comportamento do 
sistema continua a ser «aceitável» mesmo 
quando as regras vão sendo sucessivamente 
suprimidas. 

Como foi atrás descrito, a adequação de 
formas opera a partir do início do conjunto 
de regras de cada vez que uma associação/ 
adequação é encontrada. Então é desenca- 
deada a acção correspondente e o processo 
volta a ser repetido. 

Contudo, na noção dum SP «puro» cada 
regra tem, supostamente, igual oportunidade 
de ser chamada — i.e. a sua posição no 
conjunto das regras não deve afectar a sua 
possibilidade de chamada para execução. 

Isto só causa dificuldades quando as con- 
dições de mais do que uma regra são equa- 
cionadas na base de dados, caso em que 
deve ser feita uma escolha para que se de- 
senvolva a acção correspondente. Têm sido 
tentadas várias aproximações para a resolu- 
ção desta dificuldade, como por exemplo as 
seguintes: 


a ordenação das regras — usa a primeira 
regra a ser associada; 

a ordenação dos dados — os dados são 
catalogados quanto à sua prioridade 
toma a regra cuja associação dá a prio- 
ridade mais alta; 

a ordenação genérica — usa a regra mais 
específica; 

a ordenação por acontecimentos — usa a 
regra mais recentemente executada. 


Lembre-se que cada regra é testada con- 
tra toda a base de dados e que as regras, 
simultaneamente activadas, podem ter testes 
em pontos completamente distintos da base. 
Claramente, o contencioso só é crítico 
quando a activação duma determinada regra 
não permita a interacção da base com ou- 
tras(s) regra(s) candidata(s). 

Assim, na forma «pura» do SP todas as 
regras devem ser testadas, em cada ciclo, 
contra toda a base, devendo ser selecciona- 
das as regras de acção, e ser feita a escolha 
sobre a qual deve ser permitida a activação 
(pelo mesmo critério). 

Contudo, como a base de dados e/ou o 
número de regras tem tendência a aumentar, 
o sistema vai-se degradando e perdendo efi- 
ciência. 

Um conjunto de sistemas de produção já 
implementados tem conseguido um certo ní- 
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vel de estruturas de controle para combater 
aquela tendência. Assim, várias estratégias 
ou «heuristicas» têm sido empregues para 
aumentar a verosimilhança de, em certos 
contextos, as regras aplicáveis serem encon- 
tradas mais rapidamente e para que todo o 
conjunto de regras não tenha que ser exami- 
nado sem o perigo de se ignorar uma regra 
aplicável. 

Deste modo, um número dos SP já imple- 
mentados mostra um maior ou menor grau 
de «procedimentação parcial» à medida que 
os sistemas aumentam com os mecanismos 
de estruturas de controle o desenho de tais 
estruturas, atendendo a que permite uma 
pesquisa eficiente sem anular as vantagens 
da flexibilidade oferecida pela orientação bá- 
sica dos SP, tem vindo a tornar-se uma ma- 
téria de intenso interesse e debate na ciên- 
cia da computação (veja, e.g. Winograd 
1975; Kowalsk 1979). 

Este é um desenvolvimento interessante 
para o contexto deste trabalho uma vez que 
permite o exame de vários estilos de organi- 
zação e gestão ao longo de um «continuum» 
de procedimentos, em vez da escolha entre 
dois extremos. 


4. O PROBLEMA COM OS DADOS: FICHEIROS 
DE DADOS VS. CÁLCULO DE PREDICADOS 


A maior parte do software usado nas empresas 


centra-se à volta do processamento de grandes 
quantidades de dados (ao contrário, por exemplo, 
das rotinas de optimização que são muito mais de 
computação intensiva sobre uma, relativamente, pe- 
quena quantidade de dados). Por isso a inflexibili- 
dade proveniente do modo como os dados são orga- 
nizados nos ficheiros e nas bases de dados são 


igualmente (se não mais) importantes do que as 
introduzidas no projecto dos programas apoiados em 
procedimentos. De qualquer modo, como será visto 
de forma abreviada, os problemas estão altamente 
inter-relacionados. 

Um apontamento terminológico. Na última secção, 
O termo base de dados era usado para designar o 
armazenamento dos dados dum sistema de produ- 
ção. Nesta secção, esse termo será mais utilizado 
na acepção do sistema de gestão de bases de da- 
dos (SGBD). Mais à frente compararei as duas pers- 
pectivas nos pontos em que são distintas como ba- 
gi de dados dos SP ou como bases de dados dos 

BD. 

Para já, no entanto, quero falar acerca da pers- 
pectiva geral da manutenção dos dados nas aplica- 
ções de processamentos dos mesmos, quer estes 
dados sejam ou não acedidos através dum SGBD. 
Usarei por conseguinte, o termo «ficheiro de dados» 
para indicar um ficheiro de dados convencional ou 
um segmento lógico duma base (e.g. os tuplos de 
uma relação simples numa base relacional, as ins- 
tâncias dum registo simples na base de dados CO- 
DASYL). O termo «base de dados» será então 
usado para referir uma colecção de tais ficheiros 
com assuntos inter-relacionados (e.g., ficheiros de 
vendas, ficheiros de stocks, ficheiros de devoluções), 
quer, ou não, o acesso a estes seja coordenado por 
um SGBD. 

Os ficheiros de dados são, normalmente organiza- 
dos como uma tabela rectangular com colunas eti- 
quetadas chamadas «campos». Por exemplo, um fi- 
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cheiro de empregados deverá ter campos para o 
nome do empregado, morada, idade, salário, etc. 


FICHEIRO DE EMPREGADOS 


[ee [esa |] 
CEEE ER 
ess [orem | 6] 


Por vezes os ficheiros de dados têm uma organi- 
zação mais complicada, por exemplo algumas colu- 
nas podem ter entradas múltiplas para o item dum 
determinado dado. Contudo, aquela disposição ta- 
bular é suficiente para os objectivos aqui pretendi- 
dos. Por outro lado, é também esta a perspectiva 
básica nos modelos de gestão de bases de dados 
mais populares (i.e. Rede, Relacional). 

Note que cada ficheiro tem três níveis de descri- 
ção: o nome do ficheiro (e.g., EMPREGADOS), os 
nomes dos campos (ed NOME, IDADE), e os valo- 
res dos dados (e.g. SMITH, 37). É também impor- 
tante notar que um ficheiro de dados é uma repre- 
sentação conceptual de alguns aspectos da empre- 
sa, neste caso, representam-se, o que são consi- 
deradas, as características mais relevantes dos em- 
pregados. 

A estrutura de um ficheiro de dados contém tam- 
bém, muitas vezes, informações implícitas. Neste 
exemplo, cada linha do ficheiro implica a existência 
de alguma entidade envolvida, neste caso um em- 
pregado associado com a empresa. Por vezes é 
também feita uma relação casual, e.g., se o nome 
da pessoa não aparece no ficheiro então ele(a) não 
é empregado(a). 

Outros ficheiros, no entanto, podem ter outros ti- 
pos de relações, por exemplo, um ficheiro de stocks 
de elementos: 


24,000 


Este ficheiro indica o número de identificação (ID/ 
N, a cor, o peso (WT) e a quantidade ao lado das 
várias partes manufacturadas. Neste caso, cada li- 
nha do ficheiro não implica a existência da compo- 
nente, mas somente contribui para a caracterização 
de cada um dos tipos da componente. O stock ac- 
tual de cada componente é, por sua vez, indicado 
pelo campo QTY. 

Estas podem ser consideradas relações de quanti- 
ficação associadas ao ficheiro. Outras relações re- 
ferem-se aos valores possíveis que podem aparecer 
num dado campo, e.g., que o salário deve ser in- 
ferior a 50 000. 

Contudo, o aspecto básico, é que a própria estru- 
tura do ficheiro de dados não é por si só, suficiente 
para explicitar todas as relações. Em vez disso, es- 
tas aparecem na lógica dos programas que interpre- 
tam estes ficheiros. Assim, o modelo de organização 
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representado pelo sistema de aplicações existe não 
só nos ficheiros como também em vários programas 
da aplicação. Este é um problema já detectado há 
algum tempo na gestão das bases de dados e que 
tem aberto campo a um determinado número de 
aproximações que sugerem a separação das chama- 
das «restrições das bases de dados», condições que 
os dados na base devem sempre preencher. Tais 
restrições fazem parte duma tabela à parte que é 
verificada por cada um dos programas de actualiza- 
ção. Contudo, estas aproximações não têm ido sufi- 
cientemente longe. Permanece um problema básico 
que tem a ver com a própria noção do «dado» em si 
mesmo. 

Em todos os processamentos de ficheiros e siste- 
mas de gestão de base de dados, existe uma distin- 
ção entre estrutura do dado e o dado em si mesmo. 
O que eu chamei nomes dos ficheiros e nomes dos 

- campos, são elementos da estrutura dos dados na 

perspectiva aqui apresentada. (Outras perspectivas 
dos dados podem ter elementos de estrutura adicio- 
nais). Assim, por exemplo, na representação dum 
ficheiro de componentes acima apresentada, nós te- 
mos para a primeira linha; Cor = «RED», onde o 
conjunto de três caracteres «RED» é o valor do 
campo COR. A questão é que estes valores dos 
dados são olhados mais como um conjunto de 
caracteres do que como a caracterização dos objec- 
tos no seu contexto. Perspectivando apenas como 
um conjunto de caracteres, somos incapazes de es- 
pecificar mesmo as relações mais elementares entre 
as propriedades; por exemplo, se uma coisa tem 
uma cor, ela deve ser um objecto físico, portanto, 
tem peso, ocupa espaço e tem uma determinada 
localização geográfica. 

O problema básico é que as variáveis nos mo- 
delos de gestão de dados abarcam mais conjuntos 
de cadeias de caracteres (denominados «atributos 
de domínios» no modelo relacional) do que objectos 
no seu contexto. 

Por exemplo, uma restrição, numa base de dados 
do tipo que todas as componentes são quer verme- 
lhas, quer azuis ou brancas, apareceria mais ou 
menos assim: 


PART COLOR = «RED» OR «BLUE» OR «WHITE» 


Para se reconhecer que estas são propriedades 
dos objectos do meio ambiente, uma notação do 
cálculo de predicados deve ser usada, introduzindo a 
variável X para delimitar estes objectos 


1 Yx PART (x) — RED(x) OR BLUE(x) OR 
WHITE(x) 


(O símbolo Y significa «para todas»). A vantagem 
da utilização deste formato consiste na possibilidade 
de elaborar mais propriedades gerais, i.e., não só 
das componentes, como de qualquer coisa que te- 
nha cor. 


2. VYx RED(x) OR ORANGE(x) OR 
YELLOW(x) OR GREEN(x) OR BLACK(x) 
<— COLORED(x) 

3. Yx COLORED(x) — PHYSICAL-OBJECT(x) 

4. Yx PHYSICAL-OBJECT(x) > 3 nn> 0 

8/WEIGHT(x) = n 


(O símbolo « 3 » significa «existe algum»). 

A asserção (2) é uma disjunção de todos os no- 
mes das cores usadas na estrutura, indicando que 
qualquer destes implica a característica genérica de 
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serem coloridos, e vice-versa, que o ser colorido 
implica uma dessas propriedades. A asserção (3) diz 
que qualquer coisa que é colorida é também um 
objecto físico (embora alguns objectos físicos — e.g. 
vidro, espelhos — possam não ser coloridos). A 
asserção (4) diz que, para qualquer objecto físico, 
existe sempre algum número positivo que é o seu 
peso (pressupondo-se, para medida, a adopção de 
alguma medida de peso). 

A direcção pretendida com este exemplo deve ser 
clarificada. Reconsidere o problema da transportabili- 
dade do conhecimento discutido na secção 2. Clara- 
mente, há muitas conexões do senso comum exis- 
tentes entre propriedades, com que qualquer organi- 
zação concordaria — e.g., a física simples das 
cores, pesos, dimensões, etc. Estas regras seriam 
aplicáveis a qualquer objecto físico, desde amen- 
doins até carrocerias de automóveis. Outras classes 
de propriedades devem ser circunscritas a determi- 
nados sistemas sociais — e.g., o número de cônju- 
ges que um(a) empregado(a) poderá ter, o reconhe- 
cimento da dupla nacionalidade. Outras classes de 
propriedades são apenas pertinentes para determi- 
nados sectores de produção dum dado sistema so- 
cial — e.g., a contabilidade dos bancos versus a das 
instituições educacionais. Por fim, há claramente, 
aquelas propriedades que são específicas das orga- 
nizações como sejam as categorias profissionais do 
seu pessoal. 

Idealmente a inter-relação das propriedades de 
qualquer um destes níveis deveria ser desenvolvida 
de uma só vez — e.g., as medidas físicas mais 
comuns por um departamento de contabilidade na- 
cional ou mundial de normalização, normas de con- 
tabilidade por um departamento de contabilidade 
central, etc. Então, a tarefa de qualquer empresa 
particular ao desenvolver o seu software seria, tão 
só, especificar as diferenças entre a sua prática local 
e os módulos normalizados. 

O objectivo aqui é, contudo, oferecer uma notação 
do cálculo de predicados como alternativa à pers- 
pectiva usual da estrutura dos dados com o objectivo 
de fornecer um esquema mais rico, capaz de especi- 
ficar as inter-dependência das propriedades dos ob- 
jectos e não do conjunto de caracteres das estru- 
turas organizadas. 

Deve ser mencionado que isto não é necessaria- 
mente uma recomendação para que os factos das 
várias situações sejam armazenados nesta forma — 
a implementação fundamental deve na verdade fazer 
uso do modelo mais convencional de gestão dos 
dados — mas sim que, o mais alto nível ou perspec- 
tiva da base deve ter a forma do cálculo de predi- 
cados. 

Deve também ser mencionado que a notação do 
cálculo de predicados não é a única candidata à 
abstracção do relacionamento entre propriedades 
genéricas. As várias representações gráficas deno- 
minadas redes «semânticas» ou «associativas» par- 
tilham também esse objectivo. Contudo, o cálculo de 
predicados tem um desenvolvimento histórico mais 
longe e, pelo menos, na minha perspectiva, é uma 
representação mais robusta. O cálculo de predicados 
é, contudo, somente um esquema, uma meta-teoria 
na qual teorias mais detalhadas podem ser des- 
critas. 

Ele pode por exemplo, ser utilizado para descrever 
teorias matemáticas, nas quais as variáveis serão 
números, ou em teorias químicas, onde as variáveis 
serão elementos físicos. Assim, o trabalho real na 
prossecução desta direcção será o desenvolvimento 
dum cálculo de predicados específico aos problemas 
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de administração. Isto desenvolverá, entre outras 
coisas, a identificação de um conjunto de proprieda- 
des «primitivas» e de relações (i.e. simples predi- 
cado de utilizações múltiplas), os quais identificam 
classes especiais como pessoas e outros objectos 
físicos, dinheiro, tipos de contratos, etc. 

Um primeiro passo nesta direcção foi objecto dum 
trabalho meu (Lee, 1980). Ali, focava precisamente 
uma notação de cálculo de predicados (denominada 
CANDID), para a descrição de «contratos financei- 
ros», e.g., empréstimos, arrendamentos, políticas de 
opção em seguros, etc. Encarei isto como um co- 
meço útil para o desenvolvimento duma completa 
teoria de administração como foi aqui sugerido. 


5. COMBINANDO AS VIAS; SISTEMAS DE PRO- 
DUÇÃO E CÁLCULO DE PREDICADOS 


O objectivo da secção anterior era recomendar 
uma notação do cálculo de predicados como uma 
forma mais rica de representação. Na terceira sec- 
ção, sugeri uma aproximação através dum sistema 
de produção como um esquema mais flexível para 
especificar as acções potenciais dum sistema de 
aplicações. O passo final é combinar estes esque- 
mas, i.e. usar as bases de dados na forma do 
cálculo de predicados como bases de dados do sis- 
tema de produção. 

Realmente, sistemas de produção agindo sobre 
bases de dados na forma de cálculo de predicados 
têm sido usados em regime experimental há já al- 
gum o na área da Inteligência Artificial (Nilsson, 
1980). 

Os sistemas, com esta concepção, são geralmente 
denominados de «demonstração de teoremas» na 
medida em que a função dum sistema de produção 
é procurar e/ou demonstrar algum teorema, baseado 
num conjunto de axiomas iniciais da base. O termo 
«demonstração de teoremas» não é, contudo, confi- 
nado à simples demonstração matemática dos teore- 
mas. Como foi notado, na secção anterior, o cálculo 
de predicados pode ser usado para representar um 
vasto domínio de assuntos para além da matemá- 
tica. 

Onde a finalidade da base de dados é descrever 
factos e relações entre propriedades do contexto, a 
função do sistema de produção é a dedução de 
novos factos e relações. Assim, as regras de produ- 
ção, nesta concepção, tornam-se regras de inferên- 
cia para o cálculo de predicados; isto é, elas servem 
para obter novas asserções a partir dos originais. 
Estas regras de inferência são «preservadoras da 
verdade»; se as asserções originais são verdadeiras, 
assim também o serão as deduzidas. 

O esquema geral do cálculo de predicados fornece 
um determinado número de tais regras de inferência. 
Estas regras são «analíticas» naquilo em que se 
aplicam indiferentemente do domínio onde actuam. 
Num cálculo de predicados «aplicado» novas regras 
sintéticas de inferência podem ser aplicadas especifi- 
camente a este domínio, desde que o seu objectivo 
esteja especificado. 

O desenvolvimento de tal estrutura de inferência 
para um contexto de organização administrativa é, 
assim, outra tarefa para a direcção da investigação 
aqui proposta. 
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6. COMENTÁRIOS FINAIS 


O problema inicialmente colocado era duplo: as 
dificuldades envolvidas na modificação do software 
como resposta a mudanças organizacionais; e o pro- 
blema da «transportabilidade do conhecimento» i.e. 
as dificuldades na utilização de partes de software 
previamente aplicado, no desenvolvimento de novos 
sistemas. 

As causas desta inflexibilidade nos sistemas de 
aplicações foram diagnosticadas como sendo, por 
um lado, a construção de programas de procedimen- 
tos e, por outro, a perspectiva dos dados como es- 
truturas de conjunto de caracteres. Como resposta 
ao problema dos programas, foi sugerida uma via 
através dum sistema de produção; como resposta ao 
problema da estrutura dos dados, foi proposta uma 
formalização através do cálculo de predicados, ao 
mesmo tempo que foi feita uma observação final 
sobre a possibilidade de combinar os dois es- 
quemas. 

Num pequeno trabalho como este, é-se forçado a 
omitir certos detalhes e, talvez, ultra simplificar ou- 
tros. Tentei demonstrar que a arquitectura do soft- 
ware aqui sugerida é uma solução possível para os 
problemas identificados. A maior dificuldade desta 
proposta é o desenvolvimento do que pode ser cha- 
mado uma «lógica dos dados de administração», 
i.e. uma representação do cálculo de predicados e 
das regras de inferência com ela associadas que 
assimilem o conhecimento específico da administra- 
ção das organizações. Como mencionei, um passo 
inicial nesta direcção foi feito em (Lee, 1980). Ela- 
boração posterior é, contudo, necessária antes que 
vantagens práticas, para as aplicações administrati- 
vas, possam ter lugar. 
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SABE QUE: 


— NOS ÚLTIMOS 25 ANOS O HARDWARE, TEVE UM AUMENTO DE EFICIÊNCIA, 


DE TALVEZ, UM MILHÃO DE VEZES. 


— NO MESMO PERÍODO, A PRODUTIVIDADE DE UM PROGRAMADOR AUMENTOU 


ENTRE 2 À 3 VEZES. 


— A SITUAÇÃO NA ESMAGADORA MAIORIA DOS SERVIÇOS INFORMÁTICOS É EM 


ESQUEMA. 
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SABE AINDA QUE OS SEUS PROGRAMADORES PODEM RENDER 2, 
VEZES MAIS AO UTILIZAREM SOFTWARE DA INFORMATICS? 


RESOLVA OS SEUS PROBLEMAS... CONHEÇA A LINHA 
DE “IMPLEMENTATION SYSTEMS” DA INFORMATICS 
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INFORMÁTICA 


1. OBJECTIVOS DO INQUÉRITO 


Consideramos que a divulgação, na revista, dos 
trabalhos de informática de gestão que já estão em 
exploração corrente, é importante para que os lei- 
tores se apercebam do que vai sendo feito em Por- 
tugal neste domínio. Esta percepção é enriquece- 
dora na medida em que pode evitar que se repitam 
erros, aumentando-se assim a produtividade do tra- 
balho informático reduzindo-se os custos do desen- 
volvimento de novos projectos. 

É evidente que as aplicações não podem ser 
transpostas, mecanicamente, duma empresa para 
outra pois, como é sabido, cada uma contém as 
suas características próprias e, como refere o artigo 
do Ronald Lee, até mesmo uma aplicação trivial — o 
processamento de salários, não é passível de, no 
estádio actual de conhecimentos, aplicação univer- 
sal. No entanto é, por outro lado, um facto indismen- 
tível que o conhecimento do que já existe num deter- 
mindo domínio da informática, facilita o desenvolvi- 
mento de trabalhos nesse mesmo domínio. 

Foi a partir destes pressupostos que seleccioná- 
mos um grupo de empresas que pudessem reflectir 
os seguintes critérios: 


— Inserção em ramos de actividade distintos; 


2. APRESENTAÇÃO DE RESULTADOS 


INFORMÁTICA 


Algumas aplicações 
de Informática de Gestão 
desenvolvidas em Portugal 


A. CARACTERIZAÇÃO (SUMÁRIA) DO HARDWARE 


Marca/Modelo do IBM 4341 NCR CRITERION 


id 


Dimensão da UCP 2048 KB 1,5 MB 
Dimensão da memória periférica 1200 MB 800 MB 


Tipo de Exploração da Memória DOS/VSE 
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— Diferentes dimensões; 
— Utilização de equipamentos informáticos vários. 


Como referimos noutro local, a lista das empresas 
contactadas foi a seguinte: BONANÇA, JERÔNIMO 
MARTINS, LIMA MAYER, QUIMIGAL, SOCIEDADE 
CENTRAL DE CERVEJAS, UNIÃO DE BANCOS 
PORTUGUESES e VERBO. 

Evidentemente que muitas empresas ficaram de 
fora e julgamos que, para um trabalho de maior 
fôlego, a lista deve ser alargada de forma a que os 
resultados a obter sejam mais proveitosos. 

No entanto, apesar de se aguardarem respostas 
ao inquérito durante um espaço de tempo bastante 
razoável (3 meses), a realidade é que não foi possí- 
vel obter respostas senão em relação a 2 empresas: 
QUIMIGAL e SOCIEDADE CENTRAL DE 
CERVEJAS (SCC). Haverá, concerteza, várias expli- 
cações para esta situação. Pensamos que algumas 
delas se encontram na (já salientada) falta de hábi- 
tos de divulgação dos trabalhos de gestão a que, 
neste caso específico, à que juntar a inexistência 
dum tratamento estatístico dos trabalhos realizados 
pela maioria dos nossos centros de informática. Esta 
falha reside, na maior parte dos casos, na falta de 
documentação dos trabalhos que se vão realizando 
ou, na melhor das hipóteses, na existência de docu- 
mentação pouco elaborada. 


Caracter: 8 bits 

Palavra: 32 bits 

Tempo Acesso: 475 ns a 
4 caract. 

Ciclo básico: 84 ns 


Memória Virtual 
DYNAMIC ADRESS 
TRANSLATION 


inquérito aplicações 


B. CARACTERIZAÇÃO DAS APLICAÇÕES 


ie fimcora | mmefmasme ásia) Jeni 7] 
43 


N.º de programas Tempo Real - 50; Batch - 20 
Espaço ocupado = 1000 KB 

Dimensão de maior progr. 40 KB 
Dimensão de menor progr. 


Nº fich. principais 

Espaço ocupado 

Idade da Aplicação 

% Tempo gasto na sua manutenção 


SGBD ? 
Dimensão do SGBD 
SGBD utilizado 


Tempo de Desenvolv. 


Equipa 


Frequência de Util. 


Grau de Integração 


Subsidiada pelos Sistemas de Pessoal e 
Facturação de Pessoal e Facturação e 
Sub-Sistema de Gestão de Materiais 


NOTA: A aplicação da Quimigal foi seleccionada entre um total aproximado de 70. 
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First International Conference 
on Computer Applications in 
Production and Engineering 


25 a 28 de Abril 1983 


Amsterdam, The Netherlands 
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MAPPER 1100 


ENQUANTO OS COMPUTADORES 
NÃO FALAM... USE MAPPER 


nes 


SPER?Y 4 LINIVAC 


COMPUTER SYSTEMS 
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f ORGANIZAÇÃO E GESTÃO/MARKETING/INFORMÁTICA/FORMAÇÃO 


Centro de Formação da NORMA 
Av. Fontes Pereira de Melo, 31 r/c - 1000 LISBOA - Telefs. 545183 - 545220 - 545368 


Delegação no Porto 
Rua de Faria Guimarães, 383-1º - 4000 PORTO - Telefs. 402161 - 402909 


A Comunicação de Dados, é uma técnica já hoje largamente utilizada em muitas empresas, e a sua 
crescente importância económica fica bem patente através dos serviços e aplicações que suporta em 
diversos sectores de actividade. 


Muitos países europeus dispõem já de serviços públicos de comunicação de dados que virão certamente, 
em breve, a tornar-se uma realidade em Portugal. 


COMUNICAÇÃO DE DADOS 


Seminário animado pelos Eng. Santos Pato (Dep. Comun. Dados CTT) e António Carriço (BPA) a 
realizar de 24 de Jan. a 4 de Fev. 1983 (1.º Módulo) e de 21 de Fev. a 4 de Mar. 1983 (2.º Módulo) das 
09.30 — 12.30 h no Centro de Formação NORMA, em Lisboa. 


Introduzindo, desenvolvendo e analisando, o panorama, as técnicas, e as redes, de comunicação de dados, este seminário será um 
importante contributo para Instituições e Empresas que pretendam fazer a sua implementação e utilização. 


3.º Encontro de Informática 
da API 


e Hardware 
e Software 
e Formação 


Braga, 25, 26 e 27 de Março, 1983 
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9.º Congresso Mundial 
de Informática 


19-23 Setembro 1983 


Paris, França 


| — Hardware e orquitectura 


2 — Software 
3 — Fundações tecnicos do processamento de informação 
4 — Redes de computadores e comunicações 


5 — Bases de docos e sistema de informação 


6 — Sistemas apiicalivos 
7 — Sistemas de imformação para escritórios 
= microprocessadores 

Cos e económicas 


9 — Implicações 
wdo quotidiana 


10 — Compu 
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MEDINFO 83 


The Fourth World Conference on Medical Informatics vai reali- 
zar-se em 22-27 de Agosto, 1983, — RAI CONGRESS AND 
EXIBITION CENTRE, AMESTERDAN — HOLANDA 


Data limite para entrega de trabalhos prontos para publicação: 15.1.83 


Informações podem ser obtidas através de: 


MEDINFO 83 ORGANIZATION COMMITTEE c/0 1.M.I.A. 
SECRETARIAT 

PAULUS POTTERSTRAAT 40 

AMSTERDAN 

HOLANDA 


Telf. 020 - 763526 


Vol. 4, N.º 2 


INFORMÁTICA 


SORUBA 


STAXANV/KAGA 12” CHARACTER DISPLAY 


MONITORES A CORES SISTEMA 
RGB PARA COMPUTADORES 
PEARCOM, APPLE Il, APPLE ///, 
COLUMBIA, IBM PC E OUTROS. 


MONITORES MONOCROMÁTICOS 
PARA TODOS OS COMPUTADORES, 
CIRCUITOS FECHADOS DE TV, ETC.. 


COMPU-VISION-I 


50 COMPUTER PROJECTION SYSTEM 
PARA ESCOLAS, CONFERÊNCIAS, APRESENTAÇÃO 
DE NOVOS PRODUTOS, ETC.. 
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e CONCEDEMOS AGÊNCIAS EM DISTRITOS AINDA DISPONÍVEIS e 


«HARDWARE» — ASSISTÊNCIA TÉCNICA 
SORUBAL, S.a.t.l. e «SOFTWARE» 


NOVAS INSTALAÇÕES 
na Encosta das Olaias (ao Areeiro) 
Rua Aquiles Machado, lotes 10, 11 e 12 — 1900 Lisboa 
Telefs. 80 64 63/80 51 65/89 65 55/80 74 12 Telex 12775 SORBAL P 
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